こんにちは。クルーズ株式会社CTOの鈴木です。
以前の投稿で「AWS Auto Scaling によるインスタンス管理に切り替えた話」を話をしましたが、今回は、新規プロジェクトより管理画面でEC2ではなくコンテナでのサービス運用を開始した話について書こうと思います。
本番環境でコンテナ化を進めている理由
ローカル環境を含む開発環境でコンテナを利用するケースは多いですが、本番環境であえてコンテナを導入していない会社もあるのではないかと思います
その中でも本番環境でコンテナを導入することのメリットについて、私は以下のように考えています。
①インフラ保守コストの削減
単純にインスタンス費用だけで考えればEC2をはじめとする仮想サーバと変わらないか、むしろ仮想サーバのほうがコストは安く運用できるかもしれません。
ただし、一方でOSのメンテナンスはインフラ部門としてはし続けなければならず、インフラ全体の工数から見れば微々成るものではあるものの、永続的にメンテナンスコストが発生します。
コンテナを利用することでOSのメンテナンスにかかる工数を削減し、別の価値のある仕組み化を実現する工数に充てることが可能となります。
②より柔軟にスケール可能なインフラを実現し、サービスレベルを向上させるため
ここがもっともメリットとしてはとしては大きいと考えています。
現状のEC2ベースのオートスケールではスケールアウトに約10～15分ほどの時間がかかっています。
昔のように手動で構築している時と比較すれば半分には短縮できたものの、例えば急に負荷かかっても10分～15分の間のサーバ台数の増加は見込めず、その時間はサイトに繋がりづらくなったり、最悪の場合にサービスダウンの可能性があります。
コンテナを利用することにより、デプロイにかかる時間を数分に短縮が可能で、より柔軟にスケールできるインフラの実現ができることが期待できます。
③TCO(トータルコスト)の削減
デプロイ時間の短縮により、サーバの役割によっては敢えて冗長構成を行わず1台で運転することでコストダウンが図れるものがあるのではないかと考えています。
例えば、社内の特定ユーザしか使わず、仮に数分のサービスダウンであれば運用上受容可能なサービスであればシングル構成で運用する。1日数時間だけ動けばいいバッチインスタンスであれば1台構成でその時間だけ運転し、コンテナが落ちても立ち上げ直して再実行するなど。
同じサービスレベルであっても、デプロイ時間の短縮によりシングル構成で運転できるインスタンスが生まれ、その部分のコストの削減が可能ではないかと考えています。
④クラウドベンダのしばりがなくなる
コンテナ化により、ベンダー移行が容易になることが得られるメリットとしては大きいと考えています。
今までは特定のクラウドベンダーで構築した場合、仮に品質やコストに優れた後発ベンダーやサービスが出てもシステムの移行が非常に困難でした。
コンテナ化により、クラウドベンダー間の縛りがなくなり、インフラ調達面での柔軟性の向上が期待できます。
上記の理由で、Web 及びバッチについては現在コンテナ化の利用を、DBやメールサーバについてはPaaSの利用を進めており、今回は新規で構築する管理画面よりコンテナでの運用を開始しました。
コンテナ化において苦労したこと
１．ドキュメントの少なさ
今回コンテナの基盤としてAWS Fargateを使用しましたが、想定よりもトラブルシュート面でいろいろ苦労しました。
特に既定の設定でTaskを構築しデプロイしてもコンテナ内にファイル書き込みできるものと出来ないケースがあり、その原因の特定など、AWS公式ドキュメントに記載がない部分がありそれをトライアンドエラーで切り分けながらの構築であったため非常に苦労がありました。
この部分については、率直に言ってAWS側には改善いただきたい部分だt考えています。
２．デバッグのしづらさ
これはある程度仕方がない部分ですが、OS部分がマネージドになっている部分、OSを直接操作することができないので、インフラ構築面のデバッグでの苦労はありました。
結局ECS EXEC コマンドが公開されたおかげでOS側へのコマンド実行ができるようになったためデバッグは容易になりましたが、基本的にはしづらいです。
なので一度構築するまでは結構苦労する部分があるのではないかと思います。
今後の展望
現在新規構築の管理画面のみコンテナ上で運用しており、しばらく運用のナレッジの築盛期ののち、定期的に実施しているOS/ミドルウェアのバージョンアップのタイミングに合わせ逐次切り替えを行い、最終的にはWebおよびバッチインスタンスについてはコンテナに切り替えていくことを考えています。
もちろん、現時点での話なので、運用の中で出てくる課題によってはコンテナという選択肢以外にEC2のような仮想サーバを採用するケースや、AWS API Gateway＋LambdaやGCP のCloud Functionといったマイクロサービスの採用の可能性も当然ありますがまずは運用でナレッジを蓄積していこうと考えています。
