AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

バッチ処理をECSに移行した話(GitHubActionsもあるよ)その1

Pocket

はじめに

こんにちは、ハンズラボの清水です。東急ハンズのECサイトを担当しています。今回はEC2上で動いている外部ECモール連携バッチをAmazon ECS ScheduleTaskに移行しました。そして、GitHubにpushした際にECRにイメージをpushできるようなGitHubActionsも作成しました。今回はECSのScheduleTask機能を使用してバッチ処理を作成していきます。

※外部ECモールとはyahooや楽天といったショッピングサイトのことです。

既存バッチ処理の内容

既存のバッチ処理ではEC2インスタンス上にバッチサーバーを用意、cronにスケジュールを登録してバッチを叩いています。
処理の内容としては、Auroraに追加された注文変更情報を取得して、注文情報商品の数量変更、注文キャンセル等を行っています。
今回は注文情報変更処理をECSに移行しました。

ECSへ移行

移行の理由

移行の理由としては以下の点が挙げられます。

  • AWSのサポートを受けられる
  • 各バージョンアップに対応できる
  • EC2を冗長化したい
  • dockerを使用するのでローカルでの開発が楽になる

注文情報変更の処理のみをdockerのイメージとして切り出し,ECR(Amazon Elastic Container Registry)にpushします。 Amazon ECS ScheduleTaskでスケジュールを指定して、処理を開始します。

ECRの作成

ECR(Amazon Elastic Container Registry)の作成を行い、ローカル開発環境にあるdockerイメージをECRへpushします。はじめにECRでリポジトリを作成しましょう。作成したらリポジトリ名をコピーしておくと後々楽です。

dockerイメージの作成&ECRへpush

ECR(Amazon Elastic Container Registry)へpushする用のdockerイメージを作成して,pushしましょう。以下のbashスクリプトで行いました。

のちのAmazon ECS ScheduleTaskで説明しますが作成したDockerfileENTRYPOINT"/bin/ash"のようにしておくとコンテナの挙動を変更できます。(今回はpython:3.7.3-alpine3.8を使用したのでashです)

クラスターを作成

ECSからクラスターを作成します。クラスターのテンプレートですが、今回は出て行くIPアドレスを固定したいためFargateを使用せずにEC2を利用しました。 クラスターの設定は各自お任せします。

後に気づいたのですが、NATGatewayにElasticIPをつけることでFargateでもIPアドレスを固定できます。

タスクを定義

ECSからタスクを定義します。起動タイプはEC2を選択。

コンテナ定義でコンテナの追加します。イメージには先ほど作成したECRのURLのパスを貼り付ければOK。

環境のコマンドに今回はテストとしてecho testを実行します。

ログ設定のAuto-configure CloudWatch Logsにチェックを入れておくとCloudWatch Logsにログを吐いてくれるのでチェックを入れました。

タスクを実行してみる

作成したクラスター→タスク→新しいタスクの実行からタスクを実行する。 先ほど作成したクラスターとタスク定義を選択をして実行しましょう。 実行ログはCLoudWatchLogsに吐かれるので確認しましょう。

成功です。

スケジュールを設定する

作成したクラスター→タスクのスケジューリングから作成します。
スケジュールタイプはCron式でも設定できます。タスク定義を先ほど定義したタスクを設定して作成完了です。

CloudWatchLogsでログを確認したところスケジュール通りに動いてくれています。

ハマったところ

タスクが実行されない(CloudWatchメトリクスにFailedInvocationsが出ている)問題がありました。調査の結果以下の二つが問題の原因でした。

  • インターネットに接続出来ていない(ElasticIPを付与したら解決)
  • コンテナインスタンス IAM ロールに権限が付与されていない(IAMロールからECSFullAccessつけることで解決)

終わりに

今回はECSのECS ScheduleTaskを利用してバッチ処理を移行しました。次回はGitHubActionsを利用したECRへのpushを紹介できればと思います。

Pocket

wikiツールを移行した話

Pocket

不定期更新かと思ったらほぼ三ヶ月周期で記事を書いていた清水です。

みなさんは社内でどんなwikiツールを使っていますか?
今回、ハンズラボ全体とは行きませんが、現在所属しているチームのwikiツールを改めようということで、約一ヶ月かけて3つのwikiツールを使用してどのwikiツールが適しているか選定しました。

wikiツールの紹介

今回使用したwikiツールは以下の通り

どれもwikiツールとして最低限の機能は備えているので特徴的な点を紹介していきます。

DocBase

  • リアルタイムプレビュー
  • 同時編集機能
  • Markdown入力補助

同時編集機能がとてもいいと思いました。Googleドキュメントのように誰が編集しているのかも分かりますし、リアルタイムプレビューのおかげで編集が行いやすいと感じました。そして、マークダウンでテーブルを書くのは割と面倒なのですがショートカットが用意されていて便利でした。

Qiita:Team

  • リアルタイムプレビュー
  • 編集リクエスト
  • 豊富なテンプレート

編集リクエストがとてもいいと思いました。 GitHubのように変更差分の確認や通知があったりと便利。 Qiitaに投稿している人であれば、アカウントの連携やQiitaQiita:Teamの行き来ができるので普段からQiitaをみる人にとっては使いやすいと感じました。

Scrapbox

  • 独自の記法
  • 同時編集機能
  • スマホでも書きやすい

DocBaseQiita:Teamのマークダウン記法とは違い、独自の記法を使用しています。 慣れてくるとマークダウンより早くことができるので非エンジニアの人でもサクサクかけるのではと感じられました。
Scrapboxの記法

結果発表

一ヶ月3つのwikiツールを使用して、結果としてチームとして使うことになったのはQiita:Teamです!
選定要因としては毎朝Qiitaを見る人が多かったという点です。これは個人的な意見ですが PCを開く → ブラウザを開く → Qiita → QiitaTeamこの一連の流れがとてもいいと思っています。

僕自身も無意識にQiitaを開いているので、自然にwikiを見に行けます。
毎日見るサイトから流れで自社のwikiを見ることができるので、新しいwikiや更新されたwikiにも頻繁に目を通しやすくなるのでwikiのレビューが捗ります。

Qiita:TeamでもQiitaのAPIを使用することができるので、slackのスラッシュコマンドでwikiを検索するツールを作ってみたいと思っています。

こんな感じのを作っていきたいです(wikiが見つからなかったときのレスポンス)。


なる早でslackのスラッシュコマンドを作ってみる

これを機にハンズラボもQiitaのOrganizationsに参加しているので投稿できる記事が増えると嬉しいです。
ハンズラボのOrganizations

Pocket

HandsPOS 2018年までを振り返って。

Pocket

大晦日から#if swift(>=5) を少しずつ書き始めた駒場です。待ち遠しいproposalは SE-0192 です。

HandsPOSも2015年末のファーストリリースから、はや3年がたちました。iOSDC 2018でも触れましたが、そろそろ東急ハンズ店舗のレジ入れ替えも佳境です。

肌感的には今年はセミセルフレジ関連を除くと、後半はバックエンドをメンテナンスしていたので、そんなにSwiftコードを書いてない印象ですが、どのぐらいコードが書かれたのか振り返ってみる事にしました。

余談ですがNode.jsのAWS Lambdaが1年毎にEoLで死んでいって毎回トラップを踏み抜いていくのが、Appleプラットフォーム感(Swiftは4.xからは移行にあまり苦しまなくなりましたね。コンパイルエラーがあまり出なくなって若干寂しい)があって好きです。

話を戻すとLOCのカウントには cloc を利用しました。

(Swiftファイルのみ、テストコード除く)

  • v1.0.0 / 27 Nov 2015 / 19159 LOC
  • v1.7.1 / 9 Nov 2016 / 35056 LOC (+15897)
  • v2.0.7 / 12 Dec 2017 / 50396 LOC (+15340)
  • v2.6.3 / 28 Dec 2018 / 63496 LOC (+13100)

2k LOC程例年より少ないようです。

来年は消費増税(と軽減税率)がありますが、商品マスターデータ側での対応を想定しており、レジ側での対応は少なめの予定なので更に減って+1万LOC程度になるのではないかと予想しとります。平和そうですね!

それでは、ハッピーニューイヤー!

Pocket

混ぜるな危険!? ユニケージとxonshの融合

Pocket

はじめに

こんにちは清水です!
この記事は、Xonsh Advent Calendar 2018 – Qiitaの6日目の記事です。

ユニケージとは

個人的な解釈ですがawkで頑張らずともユニケージコマンドを使用することで比較的楽にshell芸ができます。

一例ですがこんなことができます。

このファイルの2列目の値だけ欲しい。
awkで書くとこんな感じ。

ユニケージコマンド(self)を使用するとこのようにかけます。

僕はまだユニケージ初心者なのでより詳細な情報は以下の記事を参照してください。

xonshとは

Pythonで作られたクロスプラットフォームのUnixライクなシェル言語とコマンドプロンプトです。
Pythonの対話モードとUnixコマンドが合体したみたいなものです。

個人的にshellなるべく書きたくないマンなのでPythonで書けるのは衝撃でした。

pipで入ります。使用するときはターミナルでxonshと打つと起動します。

ライブラリも使用できます

詳しくはこのアドベントカレンダーのリーダーである@vaaaaanquishの記事をご覧ください。

今回紹介すること

今回は謎技術ユニケージとxonshを組み合わせた「ひょっとしたら、これ使えるかもしれない(笑)」的なものを紹介していきます。

selfとのコラボ

先ほど使用したselfコマンド。このコマンドはawk '{print $1 $3}'のように出力したいフィールドを指定することでそのフィールドを表示します。

xonshと組み合わせる

いつ使うかよくわかりませんが、まぁ便利そう(pandas使ってもいいんですけどね)

殺人的なワンライナーも書けます。

mdateとのコラボ

こののコマンドは開始日から終了日を全てスペース区切りで表示します。
mdate -e <開始日(yyyymmdd)> <終了日(yyyymmdd)>

xonshと組み合わせる

split関数がいい感じにスペース区切り文字列を分割してくれるので20181201から20181231までのリストを生成できます。これは割と使えるのでなないかと個人的に思っています

dayslashとのコラボ

説明するよりも見た方が早いです。

いい感じに/を入れてくれます。 1はフィールド指定です。

xonshと組み合わせる

date_listから受け取ったdateをdayslashで/を入れてslash_dateに格納します。\nが入ってしまうのは勘弁。

Jupyter Notebookで使用する

いつものようにJupyter Notebookを使用して新規ファイルを作成しようとしたら,Xonshが入っていることに気付く。
どうやらpip install xonshするだけでJupyterのカーネルに追加されるそうです。

ユニケージコマンドは果たして使用できるのか?

実行できた!どうやらローカルのコマンドも使用できるようです。

ちなみにGoで作成したコマンドも使用できました。

Pocket

re:Invent 2018 参加レポート NPO HACKATHON FOR SOCIAL GOOD その1

Pocket

ラスベガスから日本に帰ってきました。人見です。

NPO HACKATHON FOR SOCIAL GOOD
なるものに参加して来たのでレポートします。

NPOハッカソンはre:Invent 2018のハッカソンイベントの中の1つで
複数のNPOから提示された課題の中からチームで一つ選んで開発するハッカソンです。
NPOは非営利団体のことです。

スケジュールでは9AM–MIDNIGHTと記載されており、
実際に朝8時開場で深夜1時になってもまだ終わらないという感じだったので
おそらくre:Inventのイベントの中でも最長のものだと思います。

朝のラスベガス

夜中のラスベガス

チームは5人までで、自由に組むことができます。

実は前日にハッカソンのチームを組むイベントがあったらしいのですが、
私は当日にチームを組みました。

こんな感じの紙を受付でもらって、

自分がどの役割なのかを自己紹介しながらチームメンバーを探します。
私はバックエンドエンジニアにしました。

メンバーが見つかるか不安だったのですが、
AWSの方もチームを探すのに困ったら手伝うよと言ってくれましたし、
当日オロオロしていたら、声をかけてもらえてチームに入ることができました。
すごいフランクな感じなので、英語が苦手でも大丈夫だと思います。

チームで席を決めてからは、自己紹介タイムで
自分が作ったことあるものや、使ったことのあるAWSのサービス
AWS利用歴などを話しました。
まだハッカソン開始前でお題は発表されていなかったのですが、
NPOならコストかけない方がいいからサーバーレスがいいよねとか、
DynamoDBがいいよねとか、課題を想像しながら戦略を話し合いました。

ハッカソン開始になってオープニングムービーが流れ、
各NPOから解決したい問題が発表されます。
この課題発表の英語のリスニングが超絶難しくて、ざっくりとしか概要をつかめず焦りましたが、
その後のチームメンバーとのディスカッションの時に聞いたり、
NPOの方に質問できる時間があったのでなんとか理解することができました。

私のチームはCompassionという団体の課題を選びました。
課題は「子供とスポンサーがスムーズにコミュニケーションすることができるツール」の開発です。

求められてる機能としては
・ 音声や動画のライブコミュニケーション
・ レスポンスが早いこと
・ 翻訳機能があること
・ 汚い言葉を検知して、除外すること
・ 発展途上国での通信環境も考慮すること

などなど、要件がたくさんありましたが、
ざっくりまとめると

「世界中の色々な言葉を話す子供たちと健全に会話ができるツール」

の開発です。

そんなこんなで開発がスタートしました。

その2へ続きます。

Pocket