てくすた

ピクスタ株式会社のエンジニア・デザイナーがつづるよもやまテクニカルブログです

AWS OpsWorksをやめてAmazon EKSに移行したはなし

AWS docker kubernetes インフラ コンテナ

こんにちは、開発部でインフラエンジニアをしているもりです。本年もPIXTAエンジニアブログ"てくすた"をよろしくお願いします。 今年はいよいよ東京オリンピックがはじまりますね。私は男子バスケットボール予選ラウンドのチケットが当たって、今から楽しみにしております。

さて、弊社が運営する家族向けの出張撮影プラットフォームfotowaも実は2016年2月29日のうるう年生まれ。4年に一度の「本当の誕生日」を迎えます。そこで今回はこの誕生日を迎えるにあたってfotowaのインフラストラクチャ基盤をAWS OpsWorks(以後、OpsWorks)からAmazon EKS(以後、EKS)に移行したはなしを書きます。

f:id:philip_moris:20200213130840j:plain icetray / PIXTA

移行によって改善したかったこと

OpsWorksでアプリケーションとインフラストラクチャを運用をしていく中で改善したかったことは主に下記の４つです。

  • 継続的な機能追加や改善を促進する
  • アプリケーションのデプロイ作業を省力化する
  • インフラコストを最適化する
  • モニタリングシステムの自前運用をやめたい

継続的な機能追加や改善を促進する

OpsWorksはChefやPuppetの構成管理ツールを利用し、サーバーの構成を自動化できるプラットフォームです。fotowaの場合、アプリケーションの開発言語であるRubyもその構成管理の対象となっており、継続的な機能追加や改善にインフラストラクチャがボトルネックになる可能性が課題になっていました。そこで開発言語やWebアプリケーションフレームワークの柔軟なバージョンアップを開発チームで行えるようにするため、コンテナ技術を使いその実行基盤としてEKSを採用しました。

EKSは、Kubernetes(以後、k8s)のコントロールプレーンを構築・維持する必要がなくAWSでk8sを実行できるマネージド型のサービスです。ちょうど移行を検討した時期にEKSが東京リージョンで利用可能となったり、同時期にPIXTAのサービスでもk8sへの移行を進めていたのもEKSを採用した理由のひとつです。

アプリケーションのデプロイ作業を省力化する

OpsWorksではアプリケーションのデプロイ作業を管理コンソールから実施しており作業者の負担となっておりました。この様な作業はいわゆるトイルと呼ばれSRE本では以下の傾向を持つものと定義されています。

  • プロダクションサービスを動作させることに関係する作業である
  • 手作業で繰り返し行われる
  • 自動化することが可能
  • 戦術的で長期的な価値を持たない
  • 作業量がサービスの成長に比例する

撲滅していきましょう。

インフラコストを最適化する

コンテナ基盤に移行することによって、アプリケーションの状態を維持する必要性がなくなったのでEC2のライフサイクルも変化させることが可能となります。OpsWorksではオンデマンドインスタンスを使って構成管理に主軸を置いていましたが、EKSへ移行後はコンテナの実行環境となるノードにスポットインスタンスを積極的に割り当てるようにしました。またPodのスケーリングにHorizontal Pod Autoscaler、ノードのスケーリングにCluster Autoscalerを使いシステムの負荷に応じてスケーリングする方針としました。これらにより、トラフィックやバッチの処理件数によって動的なEC2のリソース配分が可能となります。

モニタリングシステムの自前運用をやめたい

これまで、ログの可視化、インフラストラクチャの監視は異なるシステムを自分たちで運用をしており、バージョンアップ作業等の運用の手間がありました。また、異なる観点の監視を別々のツールで運用していることにより不具合の原因を特定するのが遅くなったりもしていました。そこで、１つのプラットフォームでそれらを集約・分析可能にするクラウドサービスへの移行を検討しました。

どんな構成にしたか

前述の目的を達成するため、コンテナイメージのビルドからEKSへのデプロイまでを自動化し、EKSのノードグループにはスポットインスタンスで構成されるオートスケーリンググループを適用しました。 また、モニタリングツールには、ログ、インフラストラクチャ・コンテナのメトリクスが取得できインテグレーションも豊富なDatadogを採用しました。

デプロイのプロセスとしては以下の様になります。

  • Dockerfileを含めたアプリケーションコードをGithubにプッシュ　
  • GithubのWebhooksを使いCircleCIでDockerfileをビルドしAmazon ECR(以後、ECR)にコンテナイメージをプッシュ
  • k8sのマニフェスト一式と上記のアプリケーションコンテナイメージをSourceとしたCodePipelineを実行しEKSへデプロイ
  • デプロイの完了をChatWorkに通知する
  • アプリケーションログ、インフラストラクチャの監視データはDatadogに投げる

Dockerfileをアプリケーションリポジトリへ置くことでベースイメージやライブラリのバージョンを開発チームでコントロールできる状態にしインフラストラクチャがボトルネックとならないようにしました。

fotowaの開発ではエンジニア・デザイナー共にフィーチャーブランチ毎の環境(以後、レビュー環境)が必要な場合もあり、ブランチ単位でコンテナイメージを作成しEKSへデプロイするようにしました。 それとは別に、リリース向けにステージングとプロダクション環境の計３環境が必要だったので、それぞれでCodePipelineを作成することにしました。 移行後の構成図は以下の様になります。

f:id:philip_moris:20200213132103p:plain

どんな効果がもたらされたか

プロダクション環境をEKSへ移行してからまだ数週間ほどですが、運用してみて以下の効果が出てきました。

  • レビュー環境の構築やリリース作業がgit pushコマンドで完了するので作業時間が短縮した
  • ログの検索が楽で障害や不具合発生時の調査時間が短縮した
  • EC2インスタンスのコストが移行前に比べて25％ほど削減した

f:id:philip_moris:20200212182959p:plain

まとめ

いかがだったでしょうか。 サービス開発を進めていく上でDevOpsとNoOpsそしてCostの観点でみたときの課題について、EKSを使った場合にどう解決しどんな効果があったのかをfotowaをケースに紹介させていただきました。

2020年1月にはEKSの値下げも発表され、k8sクラスタの立ち上げがより気軽になったのではないでしょうか。EKSを使ってサービスを成長させていきたい方の参考になれば幸いです。

ピクスタのサービスを成長させていきたいエンジニアを募集中です。
https://recruit.pixta.co.jp/