Zaim の Kubernetes（Amazon EKS）化の舞台裏

Zaim は家計簿からライフプラン見直しまでカバーする家計改善サービスです。Da Vinci Studio（以下 DVS）は同じくふうカンパニーグループである Zaim のインフラ運用・改善をサポートしています。

Zaim 内では、DVS が関与する以前から「Docker を導入しよう」という機運はあったものの、ノウハウがなかったことやバックエンドエンジニアが少なかったこともあり、なかなか踏み込めていなかったといいます。しかし、DVS のサポートを受けることにより、結果としてはグループ内でも先陣を切って Amazon EKS を導入し、Kubernetes 化に至りました。

今回は Zaim エンジニアの米山氏と、DVS の SRE である尾形氏に EKS 移行プロジェクトの舞台裏について DVS 社長の吉川が訊いてみました。

吉川 崇倫（インタビュアー）

Da Vinci Studio 代表取締役

尾形 知哉

Da Vinci Studio SRE

米山 直樹

Zaim サーバーサイドエンジニア

Docker 化は「やりたいけどできない」状況だった

―― 最近は Docker を取り入れる会社も多い中、ひとことで Docker 化といってもさまざまな利用方法がありますよね。
その中でも Zaim は EKS を選択したということで、今日はその経緯を含めて訊かせてください。
まず、EKS 化する前の Zaim のインフラはどういった構成でしたか？

米山 EC2 ですね。Chef でサーバーの構成を管理していましたが、AutoScalling のようなインスタンスの管理は自動化しておらず、手動で対応していました。 デプロイは Capistrano で、Jenkins からの実行でした。

―― Docker を使わない前提だと一般的な構成というわけですね。インフラの構成管理までできていない環境も多く見てきたので、Chef で管理していたと聞くと、さすがだな、しっかり管理しているなという印象を受けます。
そこから Docker 化、それも EKS 化へと舵を切ったきっかけは何だったんですか？

米山 実は、もともとは本番のインフラ環境を Docker 化するところまでは考えていなかったんです。 どちらかというと開発環境を Docker 化したいと思っていました。開発環境のメンテナンスがすごく大変だったので。

Zaim は内部的にはさまざまなシステムが入り組んだ構成で、API 用のシステム、Web 用のシステム、認証のシステムなどが独立して存在しています。それぞれで採用している言語が異なっているので、開発環境としてもバラバラです。ネックだったのは、何かを開発しようとすると関係するシステムすべてを立ち上げなければならない点でした。

一応 Vagrant で開発環境を構築するようにはしていたのですが、それらをまとめて管理していたので、すごく複雑になってしまっていて。 開発環境のセットアップにも非常に時間がかかっていました。

Zaim webページ トップ

―― おー Vagrant。やっぱり結構しっかりしていますね。
ただ、たしかに Docker と比べてしまうと Vagrant だとどうしても重くなっちゃいますよね。管理も煩雑になりそうですね。

米山 そうなんですよ。あとはこの環境の管理が属人化してしまっていて、トラブルシュートできる人間が限られていたというのもあります。 このあたりの課題は Jenkins でも起きていました。ホント、うかつに触れない状態でした（笑）。 当然、社内ではずっと問題視していて、Docker にしたいよねと話は出ていたのですが……なかなか着手できないでいたんです。

―― ほう。それには何か理由があったんですか？

米山 明確な要因があったわけじゃないんですが、社内で Docker に詳しい人がおらず、どう進めたら良いか分からないからついつい後回しに……という感じでした。 そんな折に、DVS のインフラ基盤チームが入ってくれることになったので、これを機に整備を進めましょうとなったんです。

ステージング環境から Docker 化を進めた理由

―― そうなんですね。開発環境から Docker にするのは最初のアプローチとしてやりやすいですよね。実際そういう事例も多いですし。
とはいえそんなに複雑な状態だったなら、そもそも Dockerfile 書くのも大変だったんじゃないですか？

尾形 いや、実は Dockerfile 作るのは結構スムーズに進んだんですよ。Chef のレシピがあったので。

―― ああー、そうか。本番の構成管理をベースにしたんですね。たしかにその方が環境もより揃うし健全で良いですね。
じゃあ、開発環境の Docker 化は結構すんなりできたんですね。

尾形 Dockerfile は良かったんですが……切り替えはスムーズにいきませんでしたね。

―― 切り替えというのは、開発者がローカルで起動する環境を Vagrant から Docker に切り替えるところですか？

尾形 そうです。先ほども話に出てきたように、複数のシステムに依存していたため、一気に切り替える必要があったんです。その動作検証が大変でした。

大変だった動作検証を振り返る尾形氏

―― おおお……Zaim のほとんどすべての機能の検証しないといけないってことですよね。それは大変そうだ……。

尾形 テストもあまりなく、仕様も複雑だったので、動作を確認するにしても何をどう検証すればよいのかを調査するところから進めるなど、すべてが手探りでした。 結果としては、開発環境よりも前にステージング環境を整備することになりました。実際に Docker コンテナで連携して動く Zaim をステージングに作り、社内で検証を進め、最後は一気に切り替えたんです。

―― システム間の連携部分はテストも少なくなりがちだし、暗黙的な仕様も増えてしまいますよね。
しかしなるほど、開発環境より先にステージング環境か。もともと本番の構成管理をベースにしているから逆にやりやすいんですね。考えましたね。
ただ素朴な疑問なんですが、各システムが独立しているなら、一つずつ切り替えるというのは難しかったんですか？

尾形 一部だけ Docker にして共存するのが難しかったんですよ。各システムへの依存が思ったより複雑だったのと、Chef をベースに Dockerfile を構築したので旧環境と挙動に違いがあって。

―― なるほど……開発環境を Docker 化しようとしたきっかけが逆に立ちふさがったんですね。

本番の Kubernetes 化までは足掛け一年

―― 開発環境の Docker 化の時点でかなり大変だったみたいですが、そこから本番環境を Docker 化する経緯も聞きたいです。
特に気になっているのは Amazon EKS（Kubernetes）にした理由ですね。AWS であれば Docker コンテナを実行および管理する「Amazon ECS」という選択肢もありますが、あえて EKS にしたのはどうしてだったんですか？

尾形 開発環境と同じで、本番も複数のシステム間の依存があったからですね。

例えば Zaim はテレビで取り上げられることが多々あり、EC2 で管理していたときは、テレビ放映のたびに手動でインスタンスを増設していました。これ、どのシステムをどれくらい増設するかを決めるのがすごく難しいんですよ。

―― 放送の内容によってアクセスの多さが変わっちゃいますしね。

尾形 ですです。なので読み違えると、どこかのシステムでトラフィックが詰まってしまって、あわてて対応したこともありました。

だから Kubernetes で全体を管理することで、流量などを調整しやすい形にしたかったんです。

―― ふむふむ。システム間で協調して調整する必要があるから、Kubernetes にして全体として管理しようということか。

開発環境と本番環境の課題は一見別々だけれど、根っこは共通していたんですね。
EKS になって実際どうですか？対応の手間は減りました？

米山 減ったのかな……最近、障害が起きてないからな……。

尾形 起こらなくなったんですよ（笑）。正確に言えば、ほとんどのケースは人間がいちいち対応しなくてもよくなりましたね。

米山 そういうことか（笑）。

尾形 ホント、手動オペレーションからは開放されました。

―― 良いですね〜。ちなみに本番環境の移行はスムーズにできたんですか？すでにステージング環境ができている状態からのスタートだったかと思いますが。

尾形 いや〜大変でした。開発環境の移行でステージング環境は完成していたので、動作検証はできてたんですが……。 こっちも切り替えに苦労しましたね。切り替えた後に負荷に耐えきれなくて、何度か切り戻しました。事前にしっかり負荷試験しろよって言われそうですが、シナリオ作るのが非常に難しいんです。

―― もともと読みきれなくて対応が後手に回っていた程ですもんね。

尾形 そうなんですよ。特定の負荷がかかったときに初めて顕在化する設定の漏れもありました。PHP のキャッシュとか。

米山 あれね。気づきませんでしたね。

―― 本番の移行も大変だったんですね。じゃあ今回のプロジェクト全体でいうと、かなり時間はかかりました？

尾形 開発環境の Dockerfile を作るところからいうと、トータルで一年ぐらいかかったと思います。 このプロジェクトだけやっていたわけではないので実際の工数としてはそこまでではありませんが、総期間としては長かったですね。

―― おお、結構かかりましたね。やっぱり全体を EKS 化しようと思ったらそのぐらいはかかりそうという印象ですか？例えば他社で EKS 化するとしたら。

尾形 これは当時まだ DVS で Kubernetes のノウハウが不足していたからというのが大きいですね。今からだったら、Dockerfile さえあれば一日あればできちゃうと思います。

―― だいぶ違いますね。ノウハウっていうのは、例えばどういうところなんですか？

尾形 Kubernetes 自体の知識もそうですが、エコシステム含めて全体としてどう設計するかというところですね。

例えば Kubernetes で CI/CD のパイプラインを作るとしたら、そのツールの選択肢はとても豊富で、さらにツールごとに思想も異なるので、何を選ぶべきか迷ってしまうんです。最終的に Zaim では ArgoCD を使った GitOps を採用しましたが、そこに至るまでにはどういう考え方で技術を選択していくかというのも手探りだったため、時間がかかりました。

今はこのあたり DVS の SRE チームのスタイルが確立できたので、かなり早くなりました。実際に DVS が関わっている他社でも EKS の導入は進んでいます。

Kubernetes にして感じた二つの大きなメリット

―― 安定性が向上した以外では、EKS 化してどうでしたか。何が変わりましたか？

尾形 やっぱり手作業でのスケーリングから開放されたのは大きいですね。 以前はスケーリングする必要がなくても、長期間、起動しっぱなしのインスタンスでログローテーションの対応が漏れていてトラブルになったり、プロセスが暴走してしまって対応したりといったことも起きていました。そういった現象は、発生しても自動で復旧するので、ほぼ問題にならなくなりました。こうした対応のために時間を割くこと自体が、本当に減りましたね。

米山 これは EKS ならではというわけではないのですが、デプロイがすごくラクになりました。以前はデプロイに使っていた Jenkins の設定が本当にカオスで。限られた人しか触れないし、結局、手元のマシンからデプロイということもよくありました。今は Slack から簡単にデプロイできるようになったので、デザイナーでもカジュアルに本番環境やステージング環境を更新できるようになりました。

―― いわゆる ChatOps というやつですね。

米山 そうですそうです。Zaim のサービス開発にとっては大きく変わった点の一つですね。

尾形 EKS で GitOps を取り入れたのは、開発メンバーだと馴染みがない人も多そうだったので、学習コストを減らす目的もありました。

―― 開発者の学習コストを意識しているのは良いですね。

米山 あとは、開発者もコンテナのイメージをなるべく小さくするように意識するようになりました。 それまでサーバー側の構成は、開発メンバーからするとブラックボックスに見える部分も多くありました。Dockerfile であれば触りやすいですし、イメージが小さいと開発効率も上がりますからね。

先日、たまたま数年前の Slack でのやりとりを発掘したんですけど、それが手元から手動でデプロイを試みて四苦八苦していたときの様子で。スタッフ同士でモダンになりましたねと話していました。

―― それは良かった。感慨深いものがありそうですね。

逆に EKS 化して困っているところはないんですか？

米山 システム構成のコア部分を触るハードルが上がったところですかね。単純に僕らが Kubernetes あんまり分かってないというだけなんですが。

Pod や流量とか柔軟に設定できるようになったのは嬉しい反面、そのあたりは DVS のチームにまかせっきりなので、いざ触ろうとすると、すぐには理解できない箇所もあります。 例えば ArgoCD でトラブルがあってデプロイできないとなったときに、対処に困りました。今は障害があれば DVS チームが対応してくれますが、僕らもしっかり理解したいなと思っています。最近、社内で勉強会をやっていますね。

尾形 ArgoCD のところはすみません、まだ HA（High Availability）構成にできていなくて……Sync が間に合わないケースがあったりします。まだ整備しきれていない部分は、いくつかありますね。

例えば EKS になったことで、これまで各インスタンスの中に点在していた各アプリケーションのログを集約できるようになりました。でも、フォーマットが統一できていないので、うまく活用しきれていません。 あと何も考えずにつっこむとログだけでクラウドにかかる料金が増えてしまうので、精査も必要ですね。

―― いろいろ出てきましたね（笑）。ただ、困っているのはそうなんでしょうけど悩みのレベルが上がった感じがしますね。

今、料金に関する話が出ましたが、実際のところコスト的にはどうなんですか？

尾形 Zaim のサービス自体が日々成長していることもあって単純な比較は難しいんですが、トータルで考えると少し安くなったかトントンぐらいだと思います。

言い方を変えると、コストはあまり変わらずに可用性が大きく上がったという感触ですね。

―― 可用性はそうですよね。気づかなくなったぐらいですし（笑）。コストも、変わらないといっても対応の手間や運用管理するための人的コストは下がったんですよね？

尾形 人的コスト下がった！といいたいところですが……実はあんまり変わらないですね。 スケールに関わる作業は減ったものの、Kubernetes のツール群のアップデートなどに手間がかかっていて、トータルに大きな変化はありません。

ただ、これは黎明期だからというのは大きいと感じています。EKS がマネージドでサポートしてくれる範囲も徐々に増えているので、クラスタそのものの管理業務は徐々に減っていくんじゃないかなと考えています。

今後は Circuit Breaker にチャレンジ！

最後に、これからについての質問を。

―― 今後はどういうところに取り組みたいと考えていますか？

尾形 デプロイをもっと柔軟にしたいですね。開発メンバーが増えてきたら、プルリクエストのトピックブランチごとにデプロイできるようにしたり、カナリアリリースに対応したりしていきたいです。あとはログをトレースできるようにして、開発者が安心・安全に開発できる環境を整備したいですね。

―― トピックブランチごとの環境を作りたいという要望も多いですよね。開発しやすくなりそう。夢が広がりますね。

米山 耐障害性という面では、Circuit Breaker などはまだ導入していないので検討したいですね。複数のシステムが協調しているため、過去には障害が連鎖して起きたこともありました。

あとはバッチシステム群がまだ EKS 化できていなくて。ここの移行も進めたいです。

―― Circuit Breaker カッコいいですね。たしかに、潜在的に連鎖的な障害が発生しうる構造なら取り入れたいですね。

さて、最後に。これから EKS 化を検討しているチーム、あるいは過去の自分たちに向けてアドバイスするとしたら何をアドバイスしたいですか？

尾形 最初は「コンテナ化さえできれば何でも進む！」と思っちゃうんですが、先ほどお話したように、どういったエコシステムを選択し、どう設計するかが重要です。もし知識ゼロの状態から始めるなら、結構な時間はかかると思います。

―― そういう意味だと他で機能している型を取り入れる形で導入して、それから馴染ませていくのが良いんですかね？

尾形 そうですねー、誰か詳しい人が一人でもいるだけでまったく違うと思います。

―― だからこそ今他社の環境でスムーズに EKS 化が進められているんですね。

本日はどうもありがとうございました！

インタビューは和気藹々と進みました。壁を作らず、本音で話せる環境もDa Vinci Studioならでは。