はじめに

こんにちは。ブランドソリューション開発本部　WEAR部　SREの和田（@wadason）です。普段は「ファッションコーディネートアプリ WEAR」のSREとしてクラウドの運用やリプレイスをおこなっています。

WEARはサービス開始から10年が経ち、クラウドやオンプレミスを含む大小様々なシステムが稼働しています。アプリケーションを動かすための基盤にはAmazon ECSのようなコンテナを前提としたものから、オンプレミスのAPIやBatchを動かすIISまで幅広く扱っています。そうした中で、約1年前にSREチームが結成され、技術負債の脱却やクラウドを中心としたインフラの運用を行なってきました。当初取り組んでいた大規模なリプレイス案件も落ち着き、チームメンバーが増えてきたので、現在では分散した技術スタックをKubernetesへ統一するリプレイスプロジェクトを開始しています。

本記事ではWEARにKubernetesを導入した背景や、移行にあたり工夫した事例を紹介します。Kubernetesの導入を検討している方やSREの活動事例を知りたい方に向けて、少しでも参考になれば幸いです。

導入の背景

技術負債の脱却による運用負荷の低減

こちらはWEARで利用するクラウドやAWS内のシステムを中心に利用状況をまとめた概要図です。

Fastlyによるオンプレクラウド間のパスルーティング、Akamaiによる画像リサイズなど、様々なクラウドサービスを活用しています。AWS内ではOpsWorksで構成管理するDigdagというワークフロー基盤やECSクラスタで稼働するRailsのAPIを運用しています。その他にもプッシュ通知を扱うインスタンス群が別のAWSアカウントに存在します。プッシュ通知に関する構成は後述します。

これらのシステムは構築されてから数年が経過しています。次第にシステムの複雑性が増していき、ノウハウを引き継げていない状態でした。そのため、障害や日々の運用に関して、なかなか対応のスピードを出せないという課題がありました。そこで、全社的にも広く利用されており、チーム内でも経験者が多いKubernetesに全てのアプリケーションをリプレイスしようと考えました。

GitOpsによる開発者体験の向上

アプリケーションをデプロイするために、OpsWorksスタックの仕組みや、AWSのCodeBuild、CodePipelineと様々なサービスを利用しています。障害などのイレギュラーな事象が発生した際に、このようなバリエーションの多さは素早い判断のボトルネックになってしまう傾向がありました。

普段の開発では特に課題を感じることはありませんでしたが、障害時は上の図ような複数のサービスの構成を思い出しながら調査を進めることになります。

例えば、CI/CDで利用する環境変数だけに焦点を当てても、以下を利用しています。普段は頻繁に設定を変更しないため、どこで何を設定しているのかが分かりにくい状態にありました。

• CircleCIのSecret
• AWS Systems Managerの一機能であるParameter Store
• AWS Secrets Manager

また、Railsアプリケーションをロールバックする際に、時間がかかってしまう課題がありました。 Dockerイメージをlatestタグのみで管理しているので、ECSのタスクを1つ前にビルドしたイメージでデプロイし直すことができないからです。 アプリケーションはRailsのモノレポであるため、ロジックが膨大でありテスト項目も多いです。もう1度ビルドする場合はRevertしてPull Requestを再作成し、CIによるテストを待たなければいけません。さらに、Pull Requestを適用するとDockerイメージのビルドやECSのタスクを更新するパイプラインを再度実行することになります。

そこで、従来のさまざまな仕組みを利用した複雑なデプロイパイプラインを、可視性が高くシンプルなものへ変更したいと考えGitOpsを採用することにしました。GitOpsはGitを「Single Source of Truth」として、普段行うデプロイから緊急時のロールバックまで一通りの操作を開発者が普段から利用するGitに集約できます。

GitOpsを実現するツールにはArgo CDやFlux、Jenkins Xなどがあります。WEARでは充実したGUIに魅力を感じArgo CDを選びました。

このGUIは、機能追加を行う開発チームも利用することを想定しています。 Kubernetesの導入にあたり調査や検証を行なってきたSREとは違い、ECSやOpsWorksを中心に利用してきた開発チームにとってはEKSにも慣れていく必要があります。 全社的にKuberntesの利用は活発ですが、WEARでの採用は初めてであるため、こういった分かりやすさも重要な点と考えました。

リプレイス後の構成

上述の背景を踏まえ、EKSを中心とするシステム構成へと変更しました。以下はその概要図です。 上で紹介したオンプレミスやFastly, Akamaiは今回のリプレイスの対象外となるので省略しています。

以下に重要な変更点を列挙します。

• ワークフロー基盤を扱うOpsWorksを廃止してEKSへリプレイス
• Railsアプリケーションを扱うECSの各クラスタをnamespace単位でEKSへリプレイス
• 別アカウントに存在するPush通知を扱うシステムをRailsに置き換えEKSへリプレイス（詳細は後述します）
• AWS CodeBuildやAWS CodePipelineを廃止し、すべてのシステムを後述するGitOpsによるデプロイ方法へ統一

また、リプレイスにあたり以下のAWSサービスを廃止します。

• AWS CodeBuild
• AWS CodePipeline
• AWS OpsWorks
• AWS Systems Manager Parameter Store
• Amazon ECS
• 別アカウントに存在するAmazon EC2インスタンス
• 別アカウントに存在するAmazon SQS
• 別アカウントに存在するAmazon SNS

AWSのサービスだけでも廃止できるものが多く、シンプルになったことが分かります。

EKS内で利用する様々なツール

リプレイスにあたり、他のAWSサービスと連携したりモニタリングを行うための様々なツールを導入しました。以下はその一覧です。

続きはこちら