Kubernetes+Amazon EKSで自社サーバからAWSへ サイボウズの狙いは「人がやることを減らす」
Kubernetesの活用事例を、現場から学びます。サイボウズ「kintone.com」では、自社インフラからAWSへの移行とともに、Kubernetesを用いたコンテナ化を進めていますが、オーケストレーション管理ツールに選んだのは、Amazon EKSです。決して容易ではない自社サーバからクラウドへの移行を決めたの理由は「技術的な課題」よりも「人間をスケールすること」にありました。
チームワークや業務効率の向上をソフトウェアでサポートしているサイボウズ。現在、US版の「kintone.com」で自社インフラからAWSへの移行とともに、「Kubernetes」を用いたコンテナ化を進めています。オーケストレーション管理ツールに選んだのは、2018年6月に正式版がリリースされたばかりの「Amazon EKS」でした。
自社サーバからクラウドへの移行は決して簡単なものではありません。それでもkintone.comが移行を決めた理由は、サーバがスケールしなくなったというような技術的な課題ではなく、サイボウズの開発思想を根底から変え「人間」をスケールすることにありました。
今回はkintone.comのAWS移行を進める「Yakumoプロジェクト」の担当者に、KubernetesとAmazon EKSを使った開発の長所と短所、それらを駆使しチーム一丸となって目指すDevOpsQA体制についてなど、詳しく伺いました。
- 野島裕輔（のじま・ゆうすけ／
- サイボウズ株式会社に入社後、kintoneやGaroonの自社インフラを5年ほど担当。その後、kintoneのインフラをAWSに変える「Yakumoプロジェクト」の中心メンバーとして、同プロジェクトの開発を担当している。
- 深谷敏邦（ふかや・としくに／
- 2012年にサイボウズ株式会社に入社。6年ほどインフラチームで開発を続けている。Apache、MySQL、Nginxなどを利用したクラウド基盤の構築や、VMの管理ツールの開発などを手がけ、Yakumoプロジェクトにも参加している。
「サーバよりも人のスケール」が自社サーバからクラウド移行に踏み切った理由
――kintone.comでAWSに移行している真っ最中とのことですが、移行することになった経緯を教えてください。
野島：まず、サイボウズでは現在「Yakumoプロジェクト」と題し、kintone.comのインフラをAWSに構築する移行作業を行っています。2019年中にはAWS上で動くkintone.comをリリース予定で、移行に際しオペレーションの自動化や、DevOpsQAの実現、リリースサイクルの向上を目指しています。その中でサービスをDockerでコンテナ化し、オーケストレーションツールにはKubernetes（K8s）を採用しています。
Yakumoプロジェクトが本格始動したのは2018年1月からですが、以前より「オペレーションをもっと簡単にしよう」という声があがっており、勉強会などが開かれていました。その中で私と深谷が中心になり、オーケストレーションツールの議論もしていました。
―― 現状の構成はどういったものなのでしょう？
深谷：古典的なシステム、と言えば分かりやすいかもしれません（笑）。物理サーバがあり、その上にVMを立ててアプリを入れ、ロードバランサーとデータベースがあって……という形です。
自社で持っている物理サーバが強力なので、VMのインスタンス自体もかなり大きいものを割り当てることができます。機材の調子が悪くなければ落ちることもないので、アベイラビリティも高い数値になっていると思います。IPアドレスを固定できるため、VMを作り直したとしてもIPアドレスが変化することがありません。
―― そうなるとクラウドに移す必要がないように感じるのですが、それでも移行する理由はなんでしょう。
野島：サーバのスケールよりも、人がスケールしないという問題が大きいと感じたためです。これまでのアーキテクチャだと、運用するために必要な知識が膨大になっていて……。「ここからここまで知っていいればオペレーションできる」という境目がなく、オペレーションする人間は全てを把握していないといけないという課題がありました。
例えば物理サーバが故障したり異変が起きたりしたときも、アプリを含めたシステム全体の知識がないと調査ができない状態で。それらの「知識」を全ての人間がシステマチックに把握できるようになっていればいいんですが、処理しきれていない部分がありました。
深谷：そういう課題もあり、移行によりシステムが管理する部分を増やしたいというのが狙いです。人間ができることは限られているので極力減らして、システムが自動で処理してくれるようにしようと考えています。
野島：規模が大きくなればなるほど例外的なケースは増えていきますから、「人間がやること」が際限なく増えていくと人の頭では管理できなくなってくるはずです。社内でも管理するための知識量がそろそろキャパシティを超えるんじゃないかという話になり、移行は必要という結論に至りました。
「DevとOpsの対立」をなくすため、移行プロジェクトが立ち上がった
―― 自動化によりコストを減らすことが目的、ということですね。
野島：はい。しかしそれだけでなく、冒頭でも少し触れた通り今回の移行ではDevOpsQA体制を目指しています。現状はDev（開発）とOps（運用）が分断されているため、挑戦的な新機能が投入できなかったり、逆に障害を引き起こす不具合が何カ月も放置されたりしていました。移行に伴う体制変更で開発、QA、運用チーム全員でサービスに責任を持ち、このような対立をなくしたいという狙いもあります
―― なるほど。DevとOpsが分断されていると、なぜ「境界」や「対立」が発生するのでしょう。
野島：一言でまとめるとDevとOpsでそれぞれのミッションが違うから、です。Opsはインフラの安定運用がミッションなので、リリースしたものがブラッシュアップされなくても動き続けることが重要。逆にDevは新しいものを届けることがミッションとなります。
Devが新機能をリリースしていくということは、逆をいえば障害が起きやすくなることでもあります。そうなるとOps側は、リリースをできるだけブロックしたり遅延させたりする方向に動いてしまいます。ミッションの「対立」から生まれる問題ですね。
―― Yakumoプロジェクトでは、それらの課題が解決されると。
野島：今回のプロジェクトでは、『SRE サイトリライアビリティエンジニアリング』（オライリージャパン）という本に書かれているGoogleの思想を参考にしています。そこには「まずはミッションの対立をなくす」ということが書かれています。
どういうことかというと、まずはOpsの「安定運用」というミッションをなくし、開発チームと運用チームで「ユーザに価値を届ける」という同じミッションを持ちます。そして「アベイラビリティを99.9%にする」などの「制約」を両チームに設定すれば、「リリースを行う」という状況下において、DevとOpsの立場が平等になります。「ミッションの共通化」と「制約」を設けることで、両チームにそれらを達成・守るための動きを促すんです。
ミッションの対立は現場が疲弊していくだけなので、私たちも今回の移行でチームの思想やミッションを変えていこうと考えました。
深谷：前々からインフラチームの工数が足りずリリースをブロックしてしまうなど、インフラが伴う大きな変更がしづらいという問題を抱えていたという背景もあり、Yakumoプロジェクトの担当チームを発足させて意識を変えていこう、となったんです。
―― なるほど。今回のプロジェクトは単なるクラウドの移行ではなく、チームの思想や運営の改革意識が根幹にあるのですね。現在はリリースを目指し移行を進めている最中かと思いますが、すでに問題が解決されている実感はありますか？
野島：まだなんとも言えない状況ではありますが、Kubernetesの導入による効果は大きいと思っています。
アプリケーションチームとインフラチームがそれぞれ存在するという体制はこれまでと変わりません。しかしKubernetesの導入で、インフラチームの担当領域は「コンテナを動かすまで」となり、アプリチームの開発の範囲が広がりました。Kubernetesが両チームの良い橋渡しになっています。例えば「アプリケーションサーバが5台ほしい」という要望があったとき、今まではインフラチームが物理サーバを選んで、メモリを調べて、VMを立てて、マッピングを書いて、コマンドを作って、その上でデプロイする……という作業が必要でした。しかしKubernetesを導入することで、そういった作業が自動化でき、アプリチームだけでもサーバの増設ができるようになります。
ミッションの「対立」は組織の設計変更で、 DevとOpsの責任の「境界」の位置をKubernetesで解決するのが、今回の「Yakumoプロジェクト」の目標です。
なぜKubernetes + Amazon EKSを選んだのか
―― YakumoプロジェクトのオーケストレーションツールにKubernetesを選んだ理由を教えてください。
野島：やはり「Googleが作っている」という点が大きいです。Google社内では10年ほど前からオーケストレーションツールを運営していて安心感がありますし、プロジェクト担当者の間でもKubernetesの信用度は高かったです。
他にもApache Mesos、Nomad が候補に挙がっていました。機能としてはMesosが良さそうだったのですが、情報が少なく、あまりオープン化していない印象を受けたのでやめました。
―― 一方でKubernetesの管理ツールにはAmazon Elastic Container Service for Kubernetes（Amazon EKS）を使用されていると伺いました。Google Cloud Platform（GCP）のGoogle Container Engine （現名称はGoogle Kubernetes Engine・GKE）を使用する選択もあったと思うのですが、これはなぜでしょう。
野島：Amazon EKSとGKEを単体として比較したのではなく、AWSとGCPを総合的に比較してAWSを選びました。Elasticsearchや認証・認可の機能も充実していますし、エンタープライズ系のシステムではAWSの方が向いているのかなと。AWSを選択したので、GKEではなくAmazon EKSを使用することに自然と決まりました。
深谷：あと、AWSはエコシステムが一通りそろっていて、他のインテグレーションと組みやすいという点も選択した理由の一つですね。
―― Amazon EKSはUS版が公開されたばかりですが、実際に使ってみて感じた一番のメリットを教えてください。
野島：構築が楽という一点に尽きます。個人的にKubernetesを一から構築したことがあるのですが、その際にネットワークの設定などが大変だったので「プロダクトとして実用化しようと思うとものすごく時間がかかるな」と感じました。
Amazon EKSは、AWS CloudFormationで定義を書けばすぐにデプロイできて使い始められので、煩わしさがまったくなかったですね。
Kubernetes、Amazon EKSのメリットとデメリット
―― 根本的な質問となってしまうのですが、そもそもAWSだとKubernetesではなくAmazon Elastic Container Service （Amazon ECS）という選択肢もあったのではと。候補には挙がらなかったのでしょうか。
野島：もちろん、選択肢の一つとしてありました。Amazon ECSでも機能に問題はありませんでしたが、社内でYakumoプロジェクト以外にcybozu.comにもKubernetesを導入しようという動きがあり、それに合わせてこちらもKubernetesに決めました。
深谷：実はサイボウズでもAmazon ECSを使っていた時期がありました。AWS CloudFormationと合わせて使うと、Amazon ECSもKubernetesもそれほど変わりはありません。ただ、Kubernetesの方がよりアプリを動かすのに適したワークフローを実現できる、と感じました。
野島：あとKubernetes上に載せるアプリケーションはインフラ層に依存しないように構築できるため、AWSでもGCPでもオンプレミスでも使えるという利点があります。Docker for KubernetesやMinikubeを使用すると簡単に環境が構築できますし、開発者間で同じ環境を作れれば、ワークフローを一致させることができますから。Amazon ECSとAWS CloudFormationを使うと、どうしてもAWSの環境が必要になるので、Kubernetesの方が使い勝手が良いと思います。
特定のベンダーに依存したくない場合や、手元で作業したい場合は、Kubernetesはわりといい選択肢なんじゃないかなと思います。
―― では、kintone.comのAWS移行で苦労した点はありますか？
野島：細かいものを思い出そうとするとキリがありませんが、あえて挙げるならVMの中身をステートレスにする作業ですね。既存のサービスをコンテナネイティブにしていかないといけないので、VM内に動的に変わるようなファイルを置かないよう修正していく作業が大変でした。
深谷：その作業だけでも1～2カ月くらいはかかりました……。QAを含めれば、もっとかかっているかもしれません。現状は自動テストを含めて90%ほど移行が完了していますが、運用などで必要なモニタリングなどの周辺ツールなどはまだ開発中といったところです。
―― 先ほどもお話されていたように、Amazon EKSは正式版がリリースされたばかりですが移行時に問題は起きなかったのでしょうか。
野島：やはりリリースされたばかりなので、まだバグはありますよ。Kubernetes本体は安定していますが、周辺のツールはまだ不安定な印象です。
例えば、Nodeに2つ以上のpodを配置し、LoadBalancerのタイプを設定したServiceを紐づけて通信すると、戻りパケットがドロップされるというバグがありました。
これが必ず起きるわけではないバグだったので、原因の追求に時間がかかりました。どハマりして、ひたすらダンプしてiptablesのログを出したりしていました。今はもうバグ自体が直っているので起きませんが、こういった問題はまだちょいちょい起きます。
―― それは怖いですね。Kubernetesは安定しているとのことですが、なにか気になる点はありますか？
野島：Kubernetesだとコア機能は成熟してきていますが、それ以外のあまり使われていない機能やサードパーティ周辺はまだ成熟度が低いという印象があります。そのため新しい機能が追加されると飛びつきたくなりますが、失敗することも多いですし、バージョンが上がるとデュプリケートされることもたびたびあります。
今は直っていますが、AWSのロードバランサーと連携する際に利用するingressで、Amazon EKSとの連携でぶら下がっているNodeがゼロになるバグが起きたこともありました。デプロイしてから1時間して発生する、というバグで困った（笑）
あとは新しいものを取り入れるには恒常的に人を割り当ててアップデートしていく必要があるので、それだけコストはかかると思います。
―― Yakumoプロジェクト同様に、これからAmazon EKS + Kubernetesの利用者は増えていくと思います。参考のため、現在使用しているライブラリなどを教えていただけないでしょうか。
野島：先ほど話したingressは、AWSのロードバランサーと連携する際に使った方がいいと思います。Kubernetesのロードバランサーを使用すると、AWSのClassic Load Balancerと連携することになるので設定などが若干古くなってしまうんです。
あとKubernetesはデフォルトで通信の制御ができないので、Calicoというネットワークプラグインを使用しています。Calicoを使うとどのコンテナ同士が通信できるのかを設定できるので、エンタープライズ系のシステムでは好まれると思います。
external-dnsはKubernetesのpodやサービスのIPをAWSのRoute53に自動的に登録してくれるようになるので、AWSのサービスからKubernetesへの通信設定が楽になります。
また、AWSを使用するときにはIdentity and Access Management（IAM）を使用して認証・認可を行いますが、その際はkiamというツールが便利です。Amazon ECSだとコンテナごとにIAMを割り当てることができますが、Kubernetesにはその機能がありません。そのためNodeの IAM ロールがPodに直接見えてしまいます。全ての権限が渡ってしまうことになるので、セキュリティの視点でも怖い。そういった権限を分離したいときはKiamを使って、特定のPodだけに必要な権限を渡すようにしています。
インフラを変えて、会社の仕組みも変えたい
―― では、Kubernetesはどのようなサービスや開発者におすすめできるツールだと思いますか。
野島：自分たちと同じように、DevとOpsのミッションの対立などの問題を抱えている場合に、解決を手助けしてくれるツールだと思います。
移行はかなり大変でコストもかかるので、絶対にやった方がいいことかと問われると、複雑な部分もあります。幸いにもkintone.comのアプリケーションサーバはスムーズにコンテナで動くようになりましたが、サービスの規模によっては移行に1年以上かかるというケースもありえると思います。
また、Kubernetes自体が自由度の高いツールなので、計画性なく使っていると大変なことになると思います。どう使うかは、チームやプロジェクトで最初に方向性を決めておく必要があります。
―― サイボウズ全体でもKubernetesへの移行を計画していると伺いましたが、そちらはどのくらいかかりそうでしょうか？
深谷：オンプレミスですしサービス自体も古いため、Kubernetesの導入自体が難しい点も多いと考えています。正直、かなり時間はかかると思います。
―― 移行完了を目指し奮闘中かと思いますが、現時点で改善していきたい点はありますか？
深谷：分散ロギングや分散トレーシングの部分をもっと開発していきたいと思っています。
あとは、Kubernetesを採用したことで悪いマイクロサービスパターンのようにならないよう気を付けたいです。コンテナにしたことによりサービスは増えていくので、リクエストが処理されるまで色んなものを巡回していくことになります。どこを通って何をしたのか、トラッキングしてリクエストをみるシステムは欲しいですね。サービスメッシュという言葉が、一つのポイントになっていくと思います。
野島： Continuous deliveryをきちんとやりたいです。やはりDevとOpsの分離という点が壁になることが多いので。
サイボウズはもともとユーザのサーバーにインストールするパッケージソフトを作る会社だったため、リリースは年数回という考え方でやってきていました。しかし、今は会社全体でクラウドサービスにシフトしているため、もっと高い頻度でリリースすることが求められてきています。そのあたりは自動化を増やすなどして改善していき、クラウドサービスの世界で戦っていけるようにしていきたいですね。
今回のプロジェクトでは、システムを変えるだけでなく、最終的には会社の流れも変えていきたいと思っています。例えばシステムを自動化することによって、縦方向の決定権を持っている仕組みを変えて、現在上のレイヤーがやっているような承認を下の人もできるようになればいいなと思っています。
取材：megaya {$image_10}megayaのブログ
