AWS Fargateの運用ノウハウ

ツール導入前の課題

EC2,EKSにてワークロードを構築していましたが、両者ともに運用コストが高く負担になっていました。 特に以下のような運用作業が継続的に発生していました。

• OSのセキュリティパッチ適用
• AMI更新やノード更新
• Kubernetesクラスタやノードグループの管理
• 障害時のノードレベルのトラブルシュート

これらの運用はアプリケーション開発とは直接関係がなく、インフラ運用に関する認知負荷が高い状態になっていました。 今後の事業拡大を見据えた際に、より運用負担を軽減できるマネージドサービスでアプリケーション構築をしていきたいと考えていました。 また今後ソフトウェアエンジニアが運用していくうえで、インフラレイヤーの理解コストを可能な限り下げる必要があるという課題もありました。

どのような状態を目指していたか

マネージドサービスの利用で運用コストを削減できること。 OSやホストレベルのセキュリティ対応を極力減らすこと。 スケーリングが容易で、可用性をコントロールしやすいこと。 従量課金だけではなく、ARMアーキテクチャやSpotを活用することでコスト最適化が可能であること。 ソフトウェアエンジニアが理解しやすく、運用時の認知負荷を最小化できること。

• EC2
• EKS
• ECS on EC2

• 運用コストが低減できること
• ソフトウェアエンジニアにとって学習コストが低いこと
• システム利用料がコントロールしやすいこと
• デプロイでサービスダウンしない仕組みが作れること
• スケーリングを柔軟に設定できるなど、可用性に対してある程度コントロールできること
• セキュリティ運用（パッチ管理など）の負担が低いこと

【EC2との比較】

OSの管理が不要で運用負荷が軽減できること。 セキュリティの対応が簡素化でき、認知負荷が減ること。 運用の仕方によってコスト削減が見込めること。

【EKSとの比較】

OSの管理が不要で運用負荷が軽減できること。 学習コストが低い。 サービスメッシュや複雑なマイクロサービス制御などの要件が検討当時は不要であったこと。

改善したかった課題はどれくらい解決されたか

概ね解消されました。 特に以下の点で効果を感じています。

• OS管理が不要になった
• セキュリティアップデート対応が減った
• インフラ運用の認知負荷が減少した

結果として、アプリケーション開発に集中できる時間が増えました。

どのような成果が得られたか

Terraformでモジュール化して必要なパラメータを入力するだけで簡単にデプロイできるようになりました。

これにより

• 新規サービスの立ち上げ
• 検証環境の作成

などが非常に簡単になりました。

また、インフラ構成を再利用可能なモジュールとして整理したことで、

• インフラ構築の標準化
• 再現性の向上

といった副次的なメリットも得られました。

タスク定義をどこで管理するかについてはアプリケーション側リポジトリにて管理し、デプロイと一緒に更新することとしました。ライフサイクル上アプリケーション側の都合が大きく、インフラ側（Terraform）で管理すると運用負荷が高まるからです。

また、Spot利用する時は予期しないタイミングでシャットダウンが発生します。そのためシャットダウンシグナルをイベントとして検知、通知することで状況を把握できるように設定しました。

Spotと絡む話だとALBと併せて利用する場合に、ターゲットグループのderegistration_delayを考慮することで安全にシャットダウンできるよう工夫しました。

運用コストの削減という観点では、大きくメリットがあるかと思います。

インフラとしてのコスト効率を高めるなら、EKSやECS on EC2などに移す可能性はあります。