Recruit Tech Blog
本番環境にAWS Fargateを採用しました
砂川 辰徳
本記事は リクルートライフスタイル Advent Calendar 2019 7日目の記事です。
じゃらんnetを担当している砂川です。
じゃらんnetでは一部の機能を AWS Fargate上に構築して提供しています。 リリースから数ヶ月経ちましたが、安定して運用することができています。 本記事では、AWS Fargateを採用するにあたって、技術選定時に考えた観点、本番運用するために取り組んだトピックについて書いていきたいと思います。
AWS Fargateとは
AWS Fargateとは、AWSが提供するマネージドなコンテナ実行環境です。Aamazon ECS の起動タイプとして選択することで利用できます。Amazon ECSのもう1つの起動タイプであるEC2起動タイプと比較すると、コンテナを実行するサーバを直接意識する必要がなく、サーバのインスタンスタイプの選択やクラスタ管理がいらないという大きなメリットがあります。
AWS Fargateを選定した理由
今回のプロジェクトでは、 少人数チームによるDevOps体制を構築することにチャレンジしていました。また、集まったチームメンバーのスキルセットとしてはアプリケーション開発がメインだったため、
- シンプルなインフラ構成であること
- クラウドのマネージドな製品を積極的に利用し、インフラ運用にかける手間を下げること
を念頭においた技術選定を行いました。
AWS Fargateの他に候補としてあがった要素技術として
- Kubernetes (Amazon EKS)
- FaaS (AWS Lambda)
も候補にあがりました。
Kubernetesとの比較
AWS Fargateと同様に、コンテナを利用できる点において運用の手間の削減を期待できます。一方で、今回開発する機能は複数サービスに分けるほどの規模ではなく、複雑なオーケストレーションは必須ではありませんでした。アプリケーション開発者中心のチームにおいては、Kubernetes自体の学習コストが高くなってしまうと判断し、採用を見送りました。
FaaSとの比較
FaaSを利用することでコンピューティングをフルマネージドにでき、運用の手間の削減を期待できます。しかし、FaaSを用いたアプリケーション開発だと、普段慣れているアプリケーション開発のパラダイムとは異なるところがあり、チームメンバーのスキルの強みを活かせなくなる懸念がありました。
以上をもとにAWS Fargateの選定理由をまとめると、
- Amazon ECSの学習コストが比較的低い
- コンピューティングがマネージドになるため、インフラ運用の手間を削減できる
- 普段慣れているアプリケーション開発と差分が少なく、チームメンバーのスキルにフィットしている
となります。
本番運用にするにあたって取り組んだトピック
ここからは、AWS Fargateで構築したインフラで本番運用する際に取り組んだトピックについて紹介します。
モニタリング
モニタリングについては、弊社で利用実績のある Datadog に集約させています。DatadogとAWS Fargateのインテグレーションについては、こちらのドキュメントに簡潔にまとまっています。
メトリクス
CPU・メモリ利用率などのシステムメトリクスはDatadogのAgentをサイドカーコンテナとして実行して、Datadogに送信しています。
アプリケーションは、Java11 (Amazon Corretto) + Spring Boot で動作しています。 そのため、Spring Boot Actuatorで取得可能なメトリクスは、MicrometerのDatadogインテグレーションを使って、Agentを介さずに直接アプリケーションからDatadogへ送信しています。
ロギング
AWS Fargateは、ストレージが少なくアプリケーションログのファイル出力は推奨されていません。アプリケーションログは標準出力に出力し、ログドライバを経由してログプラットフォームに転送するようにします。 構築した当時は、サポートしている転送先が AWS CloudWatch Logs or splunk しかなかったため、awslogsをログドライバとして設定し、AWS Cloud Watch Logsへ転送するようにしました。
現在はアップデートが入り、FireLensを用いて転送先を柔軟に設定できるようになったようです。
クリティカルなアプリケーションログに関しては、Datadog上で集約して監視・モニタリングしたいので、AWS Lambdaを使って、AWS CloudWatch Logsをイベントソースとして設定し、Datadogのlog magagementにも転送しています。データ量による従量課金のサービスなので、全てのログは送信せず、AWS Lambda側でフィルタを設定して、監視・モニタリングが必要なログのみを対象としています。
ログのフィルタ機能は、Datadog側でも存在し、フィルタにより取り込まれなかったログの分の料金は請求されないようになっているので、どちらか管理しやすい方でフィルタリングすれば良いです。
バッチ処理
今回開発した機能の中にバッチ処理が必要なものがあったため、バッチ処理についてもAWS Fargateを使って行いました。
ざっくり構成図は以下のようになります。
今回のバッチ処理には、以下の要件がありました。
- 定期実行する
- 複数のバッチ処理があり、実行に順序性がある
1については、Amazon CloudWatch Events を使って定期実行管理を行っています。
2については、AWS Step Functionsを利用しました。AWS Step Functionsでは、タスクという処理単位を複数組み合わせてワークフローを整理することができます。 例えば、「バッチ処理Aのタスクが正常に終了した後に、バッチ処理Bのタスクを実行する」といった管理が可能です。 それに加え、タスクとしてAWS Fargateを起動することができるため、バッチ処理用のコンテナを実行する形で実装しました。
まとめ
AWS Fargateを利用することで、インフラ面の運用の手間をかなり低く抑えることができています。 本番運用において、いくつかアプリケーション起因の不具合もありましたが、上記のモニタリングによって検知・原因特定が適切に行えています。 シンプルな機構でキャッチアップしやすく、アプリケーション開発者でも十分扱えることができるため、少人数チームにおすすめのソリューションではないかと考えています。