AWS ECS運用のコツ
目次
コンテナ運用で意識すべきこと
ITシステムを運用するにあたり、コンテナは大きな武器となります。開発環境で動いたコンテナは大抵の場合に本番環境でもそのまま動くので、可搬性が優れており、リリース時の障害も極小化することができます。また、サーバーと異なり初期設定も最小限にすることができるため、構築コストも抑えることができます。コンテナを活用して、ITシステム運用のコストを抑えるために意識すべきこととしては、
- Immutable infrastructure
- Infrastructure as Code（IaC）
が挙げられます。本記事では、これらの言葉について解説を行いながら、AWS ECS上でコンテナを運用していくにあたり考えるべきことについて記載していきます。
Immutable infrastructureとはなにか？
Immutable Infrastructureとは、ITインフラを管理する手法の一つです。Immutable：不変の言葉が表す通り、「一度構築した本番環境には更新やパッチの提供などの変更を加えず稼働させる」という考え方に基づいたインフラ運用管理手法のことを指します。
従来のオンプレミスサーバーを基本としたITインフラでImmutable Infrastructureを実際に行おうとすると、システムの不具合対応やセキュリティ上の脆弱性に対応することができず、経営やセキュリティ上のリスクとしてIT資産が認識されてしまいます。
しかし、AWS ECSのようなコンテナの登場により、Immutable Infrastructureを実現することが可能となってきています。具体的にいうと、本番環境を変更するときは、全く同じ構成や能力のコンテナで構成されたインフラを別に用意しておき、そこで十分なテストを実施し、問題がないと判断すれば、ネットワークの接続先を本番環境からそちらに切り替え、入れ替えようというのです。
つまり、既存の環境に変更を加えるのではなく、新しい環境を別個に用意して、それに切り替えることで新機能をリリースするようにすることです。もし、切り替えた新環境に問題があっても、ネットワークを元に戻せば、旧環境に切り戻せます。
このように、クラウド上のコンテナを利用することで、今まで事実上不可能であったImmutable Infrastructureを達成できるようになってきたのです。
AWS上でコンテナを活用できるスタイルズのAWSコンテナ構築、運用サービスはこちら→
Infrastructure as Code（IaC）とは何か？
Infrastructure as Code（IaC：コードとしてのインフラストラクチャ）とは、ITインフラの構成や設定をコードにして管理していくというITインフラの運用構築手法です。ITインフラは、これまで手順書をベースとした手作業が一般的でした。
しかしながら、手順書ベースの手作業だと、手順書の作成→実行→実行時のエビデンスの取得、といったステップを踏んでいく必要があります。この場合、インフラ構築に時間がかかるだけでなく、作業自体が非常に面倒であり、また手作業である以上、作業ミスによる不具合も発生しますし、構築を担当するメンバーのモチベーションにも悪い影響を与えることもあるでしょう。
また、インフラの変更発生時に記録漏れにより構成情報がわからなってしまう、といった運用上のデメリットも生じます。 Infrastructure as Codeを導入することで、環境の構築を自動化し、人為的なミスを減らすだけでなく、コードを再利用することで環境を柔軟に展開できるようになります。
また、インフラの変更点も、コード上のDiffで比較することや、バージョン管理を行うことにより、変更の経緯や変更点も把握できるようになります。コンテナでは、デプロイのスピード感が何よりも求められるため、コードでインフラを管理し人為的なミスを減らしていくことは非常に有用です。
AWSにおけるコンテナ運用で意識すべきこと
コンテナの一般論から広げて、AWSにおけるコンテナ運用では何を意識するべきなのかを記載していきます。
サーバーレスアーキテクチャー
そもそもなぜコンテナを使うのか、という目的を考えてみると、『ITインフラの運用を楽にしたいため』『高速でアプリケーションのリリースを行っていきたいため』ということが考えられると思います。そのうえで大切になってくることとしては、サーバーレスを採用し、コンテナ以外のITインフラの運用を楽にする、ということが挙げられます。
AWSでは様々なサーバーレスサービスがリリースされており、大抵のITシステムはサーバーレスで構築可能な状態になっているため、積極的にサーバーレスアーキテクチャを採用していくといいでしょう。
ALBを使う
コンテナのロードバランシングにおいては、ALB、CLBが選択可能です。ALBでは、動的ポートマッピングやURLベースのルーティングなど、コンテナを活用していくうえで重要な機能が備わっているため、ALBを使っていくといいでしょう。
設定はSystems Managerに環境変数で管理
コンテナで稼働するタスクは、時によっては数十～数百に及ぶ可能性があります。そのような状態を考慮し、アプリケーションの環境変数は外だしして管理するといいでしょう。それによって、環境変数が変わるような場合のメンテナンスコストを最小限に抑えることができます。
AWSではSystems Managerというサービスが用意されており、環境変数や、DBへの接続パスワードやアクセスキー/シークレットキーなど秘匿するべき情報はそちらで管理すると、よりセキュアな運用が実現できます。
Service Discovery
先述のように、コンテナを利用したITサービスの運用は、場合によってはコンテナインスタンスの数が数十～数百に及ぶことがあります。それらのコンテナのサービス間の連携については、Service Discoveryを使い、DNSベースでの連携を考えるといいでしょう。
サービス登録時に一意の名前を付けておくことで、自動でRoute 53にコンテナを指すレコードが登録されるため、デプロイのたびに手動でRoute 53への登録が不要です。
デプロイ方式
コンテナのデプロイフローやデプロイ手段は多種多様に用意されています。コンテナの設定ファイルはGithubなどに格納し、ビルド後にECRにプッシュし、タスク定義を更新してサービスの入れ替えを行う、といったフローが基本的になるかと思いますが、これらのフローについてはGithub ActionやCodePipeline等を利用して、極力自動化をしておくことをお勧めします。
また、Amazon SNSなどを適宜利用して、デプロイの完了通知や、レビュー依頼を行う、といった運用を行うことも可能です。
デプロメントオプション
続いて、コンテナを本番環境にデプロイする際の方法について解説します。大量にコンテナをデプロイする場合は、自動化を進めている場合でも多少なりとも時間がかかってしまいます。したがって、本番サービスに影響を与えずにデプロイを行う必要がありますが、そのためにはBlue/Greenデプロイや、カナリアデプロイを採用するといいでしょう。
Blue/Greenデプロイは、古い環境とは別に新しい環境を用意し、新しい環境にコンテナをデプロイしてトラフィックを切り変える、という手法です。カナリアデプロイは、新しいコンテナを一部ユーザーのみが利用できるようにリリースし、新機能に問題がないことを確認しながら段階的に全体に向けて展開していくデプロイ手法です。
AWS上でコンテナを活用できるスタイルズのAWSコンテナ構築、運用サービスはこちら→
ECSのログをコンテナ単位で振り分ける
コンテナで不具合が起きた場合のトラブルシューティング時には、ログを確認することが非常に重要です。ただし、デフォルトでは、ECSのタスク定義ごとにCloudWatchLogsのロググループが作成されてしまいます。
そのような状態を回避する為に、FireLensとよばれる機能を用いて、それぞれコンテナごとでCloudWatch Logsの出力先（Log Group）を設定するようにしましょう。また、サイドカーと呼ばれるログ収集用のコンテナをデプロイしておく、という手法も有効です。
オートスケーリング
EC2と同様に、ECSにおいてもオートスケーリングが設定できます。EC2と同様に、ターゲット追跡スケーリング（特定のメトリクスのターゲット値に基づいて、サービスが実行するタスクの数を増減）、ステップスケーリング（段階的なタスクの増減）、スケジュールに基づくスケーリング（日付と時刻に基づいてサービスが実行するタスクの数を増減）が可能であるため、要件に応じたスケーリングポリシーを採用し、コンテナ運用の手間を削減していきましょう。
