みんなのウェディングはEKSで動いています

Amazon EKS Advent Calendar 2019 22日目の記事です。

ますます寒さ厳しくなる中、みなさまいかがお過ごしでしょうか。 みんなのウェディングのインフラエンジニア横山です。

Docker/kubernetes流行ってますね。弊社でもみんなのウェディングの実行基盤のEKS移行を進めてまいりました。 最終的には全てのコンポーネントをEKS上に移行したいですが、最大の難所であるアプリケーションサーバの移行が完了したので、移行を考えた理由、移行への道のりについてまとめます。

なぜ移行するのか?

そもそも、なぜDocker/kubernetesは流行っているのでしょうか? それはそれぞれ以下のようなメリットがあるためと言われています。

  • Docker

    • 環境の可搬性、再現性が高く開発効率が上がる
      本番、ステージング、開発で同一のイメージを利用することで環境ごとの差異を気にせず開発ができます。
    • 特に意識することなく構成管理が行われた状態を保てる
      DockerfileをGit管理することで、Itamae,Chef,Ansibleなどの構成管理ツールを使わなくとも構成管理された状態を保つことできます。
    • 簡単にデプロイできる
      Dockerデーモンが起動しており、作成したイメージのpullができれば稼働するのでデプロイスクリプトを書いたりといった手間がなくなります。
  • kubernetes

    • 宣言的にインフラ構成を管理できる
      kuberntes上のリソースはmanfestと呼ばれるYAMLファイルで管理されます。 このmanifestには起動するコンテナ数などを記載し、kubernetesクラスターに適用します。 kuberntesクラスターは、自らの状態が、manifestの定義と乖離した際、自動的に定義状態に収束するような変更を自らに対して行ってくれます。これによりインフラ管理の手間を減らすことができます。
    • 特に意識することなく構成管理が行われた状態を保てる
      manfestをGit管理することで、特に意識することなく構成管理が行われた状態を保つことができます。

弊社でもこれらのメリットを享受したいと考えDocker/kubernetesへの移行を決定しました。 DockerをAWSで動かしたい場合、ECS/EKSという2つの選択肢があります。 ECSは確かにシンプルで良いサービスです。弊社でも利用しています。 AWS上で初めてDockerを運用したいという場合、最適なサービスだと思います。 しかし、ECSにはAWSへのロックインというデメリットがあります。 今後、状況が変わった時に他社サービスに移行するということもあるかもしれません。 また、社員自身も今後AWS以外を利用する場合があるかもしれません。 そこで、kuberntesへの理解を深め、社員が保有する技術スキルの多様性を保つ意味でEKSを選びました。

移行への道のり

移行の具体的な手法についてはアプリケーションごとの特性もあるためここでは大まかにやったことを記載しておきます。

環境変数を全てアプリケーション側で管理する

Twelve-Factor App III. 設定にもあるように、設定を環境変数に格納することはできていましたが、一部の環境変数がインフラ側でitamaeを使って構成管理する形になっていました。 Docker化するにあたり、これらの環境変数をアプリケーション側で管理するように変更しました。 秘匿すべき情報に関してはyaml_vaultを利用してアプリケーション側で暗号化しています。

監視サービスのマネージドサービスへの移行

弊社ではもともとZabbixを利用して監視をしていました。 ZabbixでもDocker/kubernetesの監視はできそうでしたが、監視に関してはマネージド化して運用工数を下げたいという思いもあり、Datadogに移行しました。

デプロイフロー構築

デプロイフローの構築にはArgoCDを利用しました。 初めはSpinnakerで構築していたのですが、以下のような課題がありArgoCDに変更しました。

  • ChatOpsとの連携が難しい
    弊社では、Slackのスラッシュコマンドを利用して本番環境へのデプロイを行っています。
    https://blog.mwed.info/posts/infra-engineer_create_serverless-bot.html
    開発者にデプロイ方法の変更(ChatOps->コンソールにログインしてデプロイ実行ボタンを押す)という負担をかけたくなったので、API経由 でデプロイを実行する方法を探したのですが見つかりませんでした。

  • kustomizeが使えない
    ※現在は使えるようになってるようです。
    https://www.spinnaker.io/guides/user/kubernetes-v2/kustomize-manifests/
    デプロイフローを構築している当時(10月ごろ)は使えなかったので、これもArgoCDへの変更を考える理由の1つでした。

ArgoCDを使うと、上記の課題は解決されます。 Git上のmanifestを自動的にkuberntesクラスターに適用してくれるため、スラッシュコマンドの処理の中で利用するイメージを変更するコミットをGitHubのmasterブランチにpushするだけでデプロイが実行されます。また、manifestはkustomizeを使うことで冗長にならずに記載することができ、ConfigMapのバージョン管理もkustomizeが行ってくれます。
https://github.com/kubernetes-sigs/kustomize/blob/master/examples/configGeneration.md

Secretsに関してはSealedSecretを導入して管理しています。
https://github.com/bitnami-labs/sealed-secrets

まとめ

移行後、今のところ大きなトラブルもなく稼働しています。 今後、Rubyのアップデート対応やミドルウェアのアップデートを行う際に、移行前の工数と比較してみたいと思います。 手前味噌ですが、みんなのウェディングは色々チャレンジができて本当に良い会社だなと思います。