インフラアップデート！コンテナ化による課題の解決とコストの最適化

株式会社オープンエイト、インフラ基盤グループの神山です。
私は2021年に中途採用で入社してSREチームとしてインフラに注力して活動してきました。

私からは近年で実施したオープンエイトのインフラ環境アップデートについてお話しします。

以前の構成について

弊社では主にAmazon Web Services(以下：AWS)とOracle Cloud Infrastructure(以下：OCI)にインフラを構築しています。

AWSではAPIサーバ群、OCIには書き出しサーバ群を構築しています。

OCIの採用理由は他社クラウドサービスと比較して大幅に料金が安いためです。特に動画の書き出し処理には多くのサーバリソースを必要とします。そのため、コンピュートサービスの料金が安いOCIでスペックの高いサーバ群を構築しています。

以前の構成ではコンピュートサービスの仮想サーバ上へ直接必要なミドルウェアやライブラリをインストールしてシステムを実行していました。しかしこの構成では以下の課題がありました。

◆課題

• AWSスポットインスタンスの活用が難しい構築であり高コスト
• システムのアップデートで不具合が生じた場合に前バージョンへ戻ることが困難
• 開発環境、検証環境、本番環境でバージョンの統一がされていない場合がある
• 弊社システムの都合上、スケーラブルな構築が困難
• プロセス停止時に自動復旧する仕組みが構築されていない

特に以前の構成ではサーバの増減時にシステムにホスト情報を登録する必要がありました。これによりスケールイン・スケールアウトを手動で実施する必要があり、その度にプルリクエストを出さなくてはならないため非常に不便です。

当時はIaCでインフラを構築していなかったため、サーバの追加時には手作業で仮想サーバを立ち上げ、Ansibleでサーバ内の構築を行い、ロードバランサーに登録し、プルリクエストを出してシステムにホストを登録する流れが必要となっていました。

これらの問題は全てコンテナ化によって解決していくことになります。

技術選定について

コンテナ環境を利用するためにコンテナオーケストレーションツールを選定する必要があります。

AWSではElastic Container Service(以下：ECS)を採用することにしました。Kubernetesは学習コストが高く、3ヶ月ごとのアップデートが必要になります。また、EKSを採用した場合のIaC管理ではawscli、eksctl、kubectl、helm、CloudFormation(またはTerraform)といった様々なツールを利用する必要があり、煩雑化しやすいです。一方でECSを採用すると、定期的なバージョンアップが不要で、IaC管理が容易であるという利点があります。

ECS環境の構築は全てCloudFormationによるIaCで構築を行いました。ECSにはサーバレスなFargateと、EC2インスタンスをホストにする形式がありますが、今回はECS on EC2構成としました。理由は既にリザーブドインスタンス(年間契約)を購入していたことと、Fargateよりもコストを抑えることができることが挙げられます。さらにコストを抑えるためにスポットインスタンスの利用割合を7割程度に増やして運用しています。

OCIではコンテナオーケストレーションツールの選択肢が少なく、Container Engine for Kubernetes(以下：OKE)が提供されているためKubernetesを利用することにしました。OCI側のインフラ管理にはTerraformを用いました。

コンテナ化による課題解決

システム環境をコンテナ化することによって、先ほどあげた課題を全て解決することができます。

AWSスポットインスタンスの活用が難しい構築であり高コスト

ECSではスポットインスタンスが終了する際に、自動的にドレイニングが行われるように設定ができるため安全なインスタンスの停止を行うことができます。スポットインスタンスが停止した際には代わりのインスタンスがすぐさま補充されます。

システムのアップデートで不具合が生じた場合に前バージョンへ戻ることが困難

過去のバージョンへのロールバックは一世代前のDockerイメージに差し替えることで実現できます。また、ミドルウェアやライブラリのアップデートによる不具合が発生した場合でも、Dockerfileを書き換えることで簡単に過去のバージョンに戻すことができます。

開発環境、検証環境、本番環境でバージョンの統一がされていない場合がある

同一のDockerfileを利用することで、環境間でのバージョンを統一することができます。

弊社システムの都合上、スケーラブルな構築が困難

システムの連携方法を見直したため、ホスト情報の登録が不要になりました。また、コンテナの増減が容易に行われるため負荷に応じた自動スケールや、時間帯に応じたスケールが可能になりました。

プロセス停止時に自動復旧する仕組みが構築されていない

コンテナが異常終了した場合には直ちに新しいコンテナが補充されます。

また、スポットインスタンスの活用やサーバリソースのスケーリングが実現できたことでインフラのコストを大幅に削減することができるようになりました。

コスト削減率はAWS環境でおよそ20%程度、OCI環境では30%以上の削減となっています。

問題点

逆にコンテナ化をしたことによって発生した問題もいくつかあります。例えばデプロイにかかる時間が以前よりも長くなった点です。
仮想サーバに直接コードをデプロイしていた時と比較すると、Dockerイメージをビルドして、ローリングアップデートで各種コンテナを入れ替えていくのは時間がかかってしまいます。

そこで、Dockerイメージのビルド開始時に、ECS / OKEを構成するホストインスタンスの数を一時的にスケールアウトさせてローリングアップデートの速度を早めるようにしました。また、Dockerイメージをdocker buildする際には一世代前のDockerイメージを--cache-fromオプションで指定して、キャッシュを活用したビルドを実施するように工夫しました。

流石に仮想サーバへ直接デプロイしていた時よりは実行速度に劣りますが、これによってある程度の改善が見られました。

その他の問題点については見つけしだい解決しており、現在では比較的安定して稼働することができるようになりました。

おわりに

弊社サービスはお客様の利用が徐々に増えています。お客様のニーズに応えられるように、安全で強固なインフラを構築することが求められています。

インフラ構成をコンテナ化することにより、弊社で抱えていた問題を解決することができました。さらにサーバのリソース管理が容易になったことで、コストカットにも繋がっています。

サービスが継続できるようにインフラを管理することはSREチームの義務です。今後も最適なインフラを構築できるようにSREチームで管理していきます。