トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

トレタのバックエンドを ECS へ移行した話 [後編]

Advent Calendar 2020 の 4 日目の記事です。

こんにちは、 wind-up-bird です。

前回に引き続き、ECS移行について書いていきたいと思います。

  • 前編: 移行前の構成や課題、移行方針を記載しています。
  • 後編: 移行後の構成や旧環境との変更点を記載しています。

※前編をまだ読んでない人は是非チェックしてみてね!

目次

新環境

この章では、ECS移行後の構成やデプロイ方法、移行方法を紹介していきたいと思います。

全体構成

全体的な構成は以下のようなイメージです。

f:id:w1nd-up-b1rd:20201201153302p:plain

1 つの ECS クラスター上に複数の ECS Service が稼働しており、API やウェブ予約、非同期処理など、各ロールが ECS Service に対応しています。

なお、プラットフォームは Fargate を採用しました。 これはマネージドサービスを採用することで、EC2レイヤーの管理が不要になることが主な理由です。

詳細

f:id:w1nd-up-b1rd:20201201155416p:plain

EC2 の場合と似ていますがプロセスではなく、各タスク内ではコンテナが起動しています。 また、用途はそれぞれ同じですが、 Fluentd ではなく、Fluent Bit を採用しています。(詳細は後述)

AWS のリソース管理

引き続き使い慣れている Terraform を利用します。

アプリケーションとは別に、インフラ用のレポジトリを新たに作成し、AWSのリソース管理はここで完結するようにしました。 ディレクトリ構成としては以下のように Module 化して、 呼び出し元で環境毎の差分を吸収しています。

├── environments
│   ├── production
│   │   ├── main.tf
│   │   └── remote-state.tf
│   └── staging
│       ├── main.tf
│       └── remote-state.tf
└── modules
    ├── service1 ※ECS の service1 で利用するAWSリソース
    │   ├── acm.tf
    │   ├── ...
    │   └── variables.tf
    ├── common ※ECS で共通で利用するAWSリソース
    │   ├── codepipeline.tf
    │   ├── ...
    │   └── variables.tf
    ├── ...
    └── service4 ※ECS の service4 で利用するAWSリソース
        ├── appautoscaling.tf
        ├── ...
        └── variables.tf

デプロイ

旧環境では、アプリケーションのデプロイは Capistrano を利用して EC2 へデプロイを実行していました。

今回の移行に伴って、デプロイパイプラインとして CodePipeline を新規に採用しました。 CodePipeline の内部では、 CodeBuild および CodeDeploy が動作します。

f:id:w1nd-up-b1rd:20201201163352p:plain

CodePipeline の各ステージでは、以下のようなことを行っています。

ステージ 説明
Source Github からアプリケーションのソースをダウンロードします。
Build Docker build (アプリケーションのbuild)、Image のタグ付け、ECRへイメージの push を実施します。
Deploy 作成された Image を利用して、 各ECSサービスにBlue/Greenデプロイを実施します。

なお、デプロイ開始と終了時には AWS Chatbot を利用して、成功/失敗の通知を Slack に流しています。

  • 成功

f:id:w1nd-up-b1rd:20201201162027p:plain

  • 失敗(例: 特定の CodeDeploy が失敗)

f:id:w1nd-up-b1rd:20201201162111p:plain

ロギング

旧環境では、ログのルーティングを目的として Fluentd プロセスが起動していました。 今回、ECSへの移行に伴い、Firelens (Fluent bit) を導入しました。*1 これは、 Fluentd よりも軽量であることが主な理由です。

挙動としては、アプリケーションのログファイル出力に対して、 Fluent Bit は tail input プラグイン を利用して取り込みます。 その後、タグに応じて CloudWatch のロググループに配送します。 また、Upstream として、 example1.com と example2.com のサーバ(EC2のときにも利用していたログの集約サーバ)を指定しています。

設定ファイルの主要な部分を抜き出すと、以下のようになっています。*2

  • fluent-bit.conf
    [SERVICE]
        Flush 1
        Grace 30
    
    [INPUT]
        Name tail
        Path /path/to/a.log
        Tag a.tag
    
    [OUTPUT]
        Name cloudwatch
        Match a.tag
        region ap-northeast-1
        log_group_name ${A_LOG_GROUP_NAME}
        log_stream_name a.$(ecs_task_id)
        log_format json
    
    [OUTPUT]
        Name forward
        Match a.tag
        Upstream /upstream.conf
  • upstream.conf
    [UPSTREAM]
        name       forward-balancing
    
    [NODE]
        name       aggregator-1
        host       example1.com
        port       24224
    
    [NODE]
        name       aggregator-2
        host       example2.com
        port       24224

なお、Fluent Bit コンテナとアプリケーションコンテナは Fargate タスクストレージ を利用して、各コンテナで Volume マウントしています。

移行作業

上記の通り、移行先の環境が整ったので、移行作業です。

旧環境と新環境は並行稼動期間を設けて、Route53 の加重レコードを利用して徐々に切り替える方法を取りました。

  • EC2:ECS = 100:0
  • EC2:ECS = 99:1 (3日間様子見)
  • EC2:ECS = 90:10 (3日間様子見)
  • EC2:ECS = 50:50 (3日間様子見)
  • EC2:ECS = 0:100 (1週間様子見)

というように徐々にトラフィックを新環境に向けていき、ユーザ影響を可能な限り最小化するようにしました。*3

最終的に、全く問題なく移行が完了しました。

と言えればよかったのですが、残念なことに移行先の設定ミスにより一部のサービスで障害が発生してしまいました。 しかし、これも最初の 3日間 の間に発覚したので、影響は最小限にすることができたのではないかと思います。

設定ミスを修正後、移行を再開し、その後は問題なく並行稼動期間を終えることができました。

最後、旧環境を削除して移行が完了しました。

振り返り

ECSに移行してどうどうだったかまとめてみます。

Build 時間の短縮

Packer + Ansible がなくなり、代わりに Nginx と Fluent Bit の Docker イメージ作成のみとなりました。 これにより 30分以上かかっていたイメージの作成が2分程度で終わるようになりました。

EC2とOSの管理から開放された

ECS on Fargate を採用したので、EC2とOSを管理・運用する必要なくなりました。 また、Ruby の Runtime 、各サービス向けの設定ファイルはすべてアプリケーションレポジトリ単独で管理できるようになりました。 これによって、SREチームへの以来 => 作業待ちという状況も解消されました。

起動時間と費用

EC2 では起動に10分弱かかっていたのが、 ECS のタスク起動は1〜2分で完了するようになりました。 これにより、より柔軟にスケーリングポリシーを設定することができ、余剰なコンピューティングリソースの削減にも繋がりました。

結果として、33万円/月 程度の費用削減も実現できました。*4

ハマった点など

長々と移行について書いてきましたが、せっかくなので今回の移行で悩んだことやハマった点なども残しておこうと思います。

設定ファイルの管理

これは、ちょっと悩んだ点です。

前述の AWSリソースの管理はアプリケーションのレポジトリとは別に管理しています。

  • レポA : アプリケーションのレポジトリ ( Ruby on Rails )
  • レポB : インフラのレポジトリ ( Terraform )

では、この境界をどこにするのか?という点で少し悩みました。 具体的には、ECSのタスク定義や buildspec.yml ファイル、 appspec.yml はレポAで管理したほうがいいのか、それともレポBで管理するべきか?という感じです。

これは、ライフサイクルと役割という観点から、以下のようにしてみました。

  • レポA : AWS のリソース上で "何を実行するか" を管理。
    • 例: buildspec.yaml、 appspec.yaml、 タスク定義ファイルなどは、こちらで管理。
  • レポB : AWS のリソース "そのもの" を管理。
    • 例: ELB、 CodePipeline、ECSクラスタ、ECSサービスなどは、こちらで管理

これがベストではないかもしれませんが、環境変数やビルドの内容などアプリケーションの変更と連動するものは レポA に寄せたほうがよかろうと考えました。

ECS 標準デプロイアクション

これは少しハマった点です。

このブログでは詳細を記載していませんが、 トレタでは非同期処理として Sidekiq を利用しています。*5 このような ELB に紐付かない ECS サービスは当初 ECSの標準デプロイアクションを利用する予定でした。

具体的には、 CodePipeline の Build ステージで aws ecs register-task-definition を実行後、Deploy ステージで imagedefinitions.json を利用して、登録したタスク定義を反映する想定です。

しかし、 実際は、 アクション実行時にサービスに設定されているタスク定義のリビジョンを元に imagedefinitions.json に従って image プロパティのみを更新した 新しいタスク定義のリビジョンを作成するという挙動になります。 (つまり、 aws ecs register-task-definition で登録したタスク定義は使われない。)

解決策としては、

  • Build ステージでタスク定義を更新後、 aws ecs update-service を実行する。
  • CodeDeployToECS アクションを使用して、ECS サービスに対して Blue/Green デプロイを行う
  • CloudFormation デプロイアクションを使用してサービスの更新を行う

が挙げられると思いますが、今回は Blue/Green デプロイの手法を採用しました。 理由は、

  • 他サービスのデプロイと並列実行が可能
  • デプロイ方法が Blue/Green デプロイに統一できる

ためです。 一方、これには課題もあり、 Blue/Green デプロイのためだけにしか使われない ELB が必要になります。 これはAWSのサポートに機能要望として挙げたので、今後のアップデートに期待したいと思います。

16kB のログチャンクサイズ

これは、ハマったところです。

Fluent Bit 導入当初は アプリケーションコンテナはログを標準出力していました。 従って、アプリケーションログの転送経路は以下のようになります。

  1. アプリケーションコンテナ
  2. Fluentd Docker Logging Driver
  3. Docker Daemon
  4. Unix Domain Socket
  5. Fluent Bit コンテナ

※参考 aws.amazon.com

しかし、導入後しばらく経ってから、一部のログレコードが分割されていることに気づきました。 調査したところ、Docker 側の制限により 16kB でログが分割される 動作になることが分かりました。

※参考 github.com

解決策としては、(他にもあるかもしれませんが)

  • Fluentd ロガーライブラリの導入
  • 標準出力をやめて、Fargate タスクストレージにログファイルとして出力する

を考えていましたが、導入が容易だった後者を選択しました。*6

なお、タスクストレージを利用する場合は、 20GB の容量制限(プラットフォームバージョン1.4.0以降)があるので、定期的なタスク入れ替えやログローテーションの仕組みが必要になります。

最後に

2020年3月のプロジェクト発足から2020年11月に完了するまで、ずっと関わってきました。 正直な感想としては、無事に移行完了してホッとしています。

しかし、今の構成やデプロイ方法などがベストだとは思っていないので、 今後も運用しながら改善していきたいと思います。

お決まり

エンジニア募集しています!!!

カジュアル面談も可能なので、ぜひ遊びに来てください。

https://corp.toreta.in/recruit/midcareer/


*1:Fluent Bit は初挑戦だったので、検証からはじめました。結果、本番環境でも利用可能であると判断し導入を決めました。

*2:実際は、FilterStream Processing、複数ログファイル対応などもう少し複雑なことをしています。

*3:もちろん移行先で問題があれば、すぐに EC2:ECS = 100:0 に戻します。

*4:前編で記載しましたが、移行前にEC2インスタンスサイズおよび台数を最適化できていなかったことも要因としてあります。

*5:これも今回の移行対象です

*6:それ以外にも、台帳以外のシステムでも同様の仕組みを導入できそうだ、という理由もありました

© Toreta, Inc.

Powered by Hatena Blog