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

HANDS LAB

HANDS LAB ENGINEERS BLOG

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

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

Pocket

こんにちは、ハンズラボの清水です。東急ハンズのECサイトを担当しています。今回は前回の続き、GitHubのリポジトリにpushしたらECRへpushを行うGitHubActionsを紹介します。

前回の記事はこちら
バッチ処理をECSに移行した話(GitHubActionsもあるよ)その1

前回の記事の追記(Fargateになりました)

前回の記事のクラスターを作成にEC2を利用しましたが、その後、NATGatewayにElasticIPをつけることでFargateで出て行くIPアドレスを固定することができたのでFargateになりました。

IPアドレスを固定する理由は外部ECモール(yahoo, 楽天など)のAPIを利用する際、IPアドレスの制限があるのでIPを固定しています。

GitHubActionsを作成する

ここから本題!GitHubのリポジトリにpushしたらECRへpushを行うGitHubActionsを作成していきます。
参考にしたもの(https://github.com/actions/example-aws)

主な流れはこんな感じ

  1. GitHubのリポジトリにコードをpushする
  2. docker buildを行う
  3. dockerにタグをつける
  4. AWSのアカウントにログイン
  5. ECRにpushする

GitHubのリポジトリから作成します。
作成を行うとプロジェクト内に.github/main.workflowというファイルが作成されます。GitHubActionsのGUIで作成も出来ますし、main.workflowを編集して作成もできます。

個人的にはGUIで大まかな流れを作成して、main.workflowを編集するやり方が個人的には作成しやすいです。

main.workflowの見方

がっつりmain.workflowを書くことはありませんが、GUIである程度作成してしまえばいいので編集するのはenvargsくらいです。
usesは使用するdocker imageです。(独自の環境での実行もできます)

作成したもの

各説明(処理の流れ)

1. ブランチをフィルタリングする

pushされたブランチがmasterの時のみ下に処理を流します。
GitHubActionsでは条件分岐ができないのでFillterを使用しています。

2. イメージのbuild, ECRへのログイン, slack通知

ここではイメージの build、ECRへのログイン、slackへの通知を並列で実行します。

やっていることはdocker build -t test-python . –build-arg STAGE=$STAGEのコマンドを実行しています。

ECRへのログインも先ほどのdocker build同様にawsのコマンドを実行しています。secretsAWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYをセットすることでECRにログインできます。

secretsの登録は割と簡単です。

slack通知はsecretsにwebhookのURLをセットしてargsにチャンネルに通知するメッセージを設定します。

3. dockerイメージにタグをつける

行なっていることは上記のコマンドと同じですコマンドではバージョンをlatestとしていますが、GitHubActionsではバージョンにブランチ名が適応されます。

4. ECRへpushする

dockerイメージのタグ付け、ECRへのログインが終わり次第ECRへpushを行います。

行なっているコマンドは同じですがバージョンのlatestは今回masterになっています。ECSのタスク定義でイメージのURLをlatestにしている場合はmasterに変更しましょう。

5. 完了通知をslackに飛ばす

2. の工程で説明を行なっているので省略します。

masterへpushを行うと、リポジトリのActionsタブから実行ログを見ることができます。

GitHubActionsを使って見ての感想

良い点

  • 作成が簡単
  • 処理の流れが見やすい
  • Dockerとの相性が良い

悪い点

  • ブランチごとにActionsを定義できない
  • 条件分岐が使用できない(失敗したら~~するとか)
  • AWSの複数アカウントに対応できない(Keyを1セットしか登録できない)

現在GitHubActionsはPublicBetaなので今後の機能追加に期待しています。

Pocket

CRMチームの技術展望

Pocket

CRMチームのエンジニアリーダー(仮称)の倉嶋です。
(仮称)としているのは、今年度からできた役職で名称がまだ固まってないからです。
チームの組織課題について責任を負っています。

さて。自チームの技術展望について、過去・現在を元に書きます。
免責事項として、社全体の展望ではありません。自チームに閉じたものです。

過去 (2015年度以前)

  • 外部ベンダ製のパッケージから内製化への移行期。
  • オンプレミスなサーバからAmazon EC2へ移行。
  • Web・Web API・バッチの全てをユニケージ開発手法(以下、ユニケージ)で開発。
  • 開発・運用とも元販売員エンジニアが実施。

現在 (2015年度〜2018年度)

  • ほぼ内製移行が完了。AWS移行も完了。EC2以外のサービス利用が増加。
  • ユニケージが不向きと判断したシステムについては言語をPHP/Node.jsへ、データストアをDynamoDB/RDSへ移行。
  • 東急ハンズ出向者が減り、中途採用の専業エンジニアによる開発・運用。
  • ハンズラボ社としての新卒採用を開始。

過去と現在の差分

  • 内製化により、ブラックボックスとなっている箇所がごく少ない状態になった。
  • AWS化により機器故障等のハードウェア運用作業がほぼゼロになった。
  • AWS化・多言語化・NoSQL/RDB化により、必要な技術知識の幅が大きく広がる。
  • 「業務知識>技術知識」な開発者から「業務知識<技術知識」な開発者へ。

近い未来

  • 開発者が業務知識を持つ状態から、コードが業務知識を表す状態へ遷移する。
  • コードレビュー・モブプログラミングによる暗黙知の継続的な転移。
  • コンテナ技術の利用による開発言語・ツールの選択肢の増加とdeploy単位の細分化。
  • 新規参画メンバーの早期戦力化のためのオンボーディングプロセスの改善。

まとめ

より、エンジニアにとって魅力あるチームへ変えていくことが自身のミッション、と捉えています。
自チームを「参画すると成長できる」「他社・他チームから入りやすい」「休みやすい・在宅勤務しやすい」「自分が選んだ技術を使える」ものへ変えていきたいです。
先日の清水の記事「バッチ処理をECSに移行した話(GitHubActionsもあるよ)その1」はその実践の一つです。

まだ残っている2015年度以前に開発したアプリケーションもあり、順次マイグレーションを進めています。開発プロセスの改善を継続しながら、近い未来をより早く引き寄せるために、マイグレーションの速度も加速させていきたいです。

まだ、「遠い未来」については描けてはいませんが、チームのメンバーと一緒に考えていきます。
新規メンバーの募集と受入のため、「チームのJobDescriptionの作成」「OnBoardingプロセスの文書の作成」を並行して作成しています。
こちらも、いずれ公開したいです。
生煮えのプライベートリポジトリ版にご興味のある方は、ぜひ中途採用にご応募ください。その時点の最新版をお渡し致します。

※アイキャッチはフリー写真素材ぱくたそhttps://www.pakutaso.comさんの画像です。

Pocket

バッチ処理を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