CNDT2021、ミクシィのSREによるEKS移行の概要を解説するセッションを紹介

CloudNative Days Tokyo 2021から、株式会社ミクシィのセッションを紹介する。家族で写真動画を共有する「家族アルバム みてね」の運用担当エンジニアが、仮想マシンからコンテナへの移行、インフラストラクチャーアズコード（IaC）を実践するための改善点、オブザーバービリティ向上のためのNew Relic導入などを解説した。タイトルは「全世界のユーザーが快適に利用できるクラウドネイティブなシステムを目指して」、担当したのはミクシィのSREである清水勲氏だ。

ミクシィのSRE、清水勲氏がセッションを担当

サービスの紹介の後に、世界を対象にしたサービスを運用する際の課題を解説。ここでは東京にメインのサーバーが置かれている状況で世界中からのアクセスをどうやって高速化するのか、問題発生時の解決のための工夫などについて解説を行った。

SREとしての課題を解説

より安定したネットワークを実現するために、ミクシィが利用しているAWSの機能であるS3 Transfer Accelerationを使って、エッジである日本以外の国や地域からのアクセスを高速化したことを紹介。

S3 Transfer Accelerationを利用

これは海外から直接東京リージョンのS3にデータを送信するのではなく、エッジのロケーションのストレージで一旦受けてから東京リージョンのストレージに高速送信をすることで、ユーザー体験としての高速化を目指したものといえるだろう。

また通信状況や端末の環境によって起因するトラブルや遅延を検知するために、New Relicのオブザーバービリティプラットフォームを採用していることを解説した。

端末側でメトリクスを採取する仕組みを導入

ユーザーがアップロードするデータはS3に向けて送信され、メトリクスはNew Relicのクラウドサービスに向けて送信することで、サービスの運用担当者はNew Relicのダッシュボードからシステムの状態を確認することができる。

また各国で実施されるプロモーションなどの結果として起きる突発的なアクセス増加に対応するために、従来はAWS OpsWorks上で実装されたChefによって新規の仮想マシンがデプロイされる方式を改め、コンテナ化されたアプリケーションが即座にデプロイされる形式によって高速化が実現できたと説明した。

OpsWorksからコンテナでアプリケーションがデプロイされる方式に移行

ここまで世界中のユーザーが快適に利用できるための工夫を紹介した清水氏だが、ここからは開発者目線でどうしてKubernetesに移行したのか？ を解説するフェーズになった。

開発者にとっての課題を紹介

システム全体の刷新が必要という判断を受けて、仮想マシンベースからコンテナベースに移行したことになるが、その際にAmazon ECS（Elastic Container Service）を使うのか、KubernetesベースのEKSに行くのかについては議論があったという。その際のポイントは、Kubernetesのエコシステム、オープンソースプロジェクトとしてCNCFにホストされていること、結果として業界標準になりうるという判断があったのだろう。

Kubernetesを選んだ理由を解説

ただ2018年当時は、まだそれほどKubernetes自体の情報が潤沢にあったわけでもなく、AWSの東京リージョンにもEKSがリリースされていない状況であり、EKSを選択するには不安があったという。その際に、AWSのソリューションアーキテクトなどに相談することで不安が解消されていったことを紹介した。ここでのポイントは、ミクシィとしてはサービスとしてのKubernetes、つまりEKSを使おうとしていたことで、オープンソースソフトウェアとしてのKubernetesではないことだろう。ソフトウェア自体であれば、コミュニティに質問したり、コミュニティの活動を見たりしていればエコシステムとしてどのような拡がりを見せていたのかは知ることができたと思われるが、頼りにしたのはAWSのソリューションアーキテクトであることで、サービスとしてのEKSが最優先だったことがわかる。

EKSを選ぶ時の不安を解消してくれたのはAWSのソリューションアーキテクト

またシステム全体を移行するのに2年半という時間がかかったことを紹介。

システム全体の移行に2年半が必要だった

すでに仮想マシンベースのインフラストラクチャーアズコードを実践していたミクシィがコンテナに移行するに際して、GitHub＋Terraformによる運用からGitHubからの起動、Slackによる承認、開発者がAWSの管理者アカウントを使わない方式に移行した仕組みを解説。ここでのポイントは、ユーザーが自作ツールで必要なインフラストラクチャーを定義し、AWSのサーバーレスであるLambdaを経由して必要な環境がデプロイされる部分で、管理者と開発者のアカウントを分離することでリスクを軽減していることだろう。ステップとしては従来の方式のほうがシンプルに見えるが、管理者と開発者のアカウントを分離するメリットのほうが高いということだろう。

インフラアズコードを改善

またアプリケーションのデプロイも、GitHubにプルリクエストを送るだけでAWSのコンテナレジストリーからArgoCDを経由してKubernetes上のインフラに自動的にデプロイが行える仕組みが採用されているという。

GitHubとArgoCDを使ったアプリのアップデート

オブザーバービリティの向上については、New Relicが大きな役割を果たしていると言える。

ログ分析の改善やNew RelicのAPMを利用

特に携帯端末のメトリクスを収集できるのが、New Relicの売りのひとつだが、ミクシィはその利点を最大限に活用しているようだ。New Relicはクラウドサービスとしてアプリケーションのメトリクスの採取、分析を行うイスラエルのベンチャーだが、日本でも多くの企業ユーザーを獲得していることを実感するスライドとなった。

最後にまとめとして4つのポイントを解説。ここではEKSの採用、New Relicによるオブザーバービリティの実装などが紹介された。

各種改善点の紹介を行った清水氏だったが、改善の結果を具体的な数値で見せられればより訴求したのではないかと感じた。

清水氏のセッションは以下のURLから視聴可能だ。

動画：世界中のユーザーが快適に利用できるクラウドネイティブなシステムを目指して