ケーススタディ：

スタートアップはどのようにしてKubernetesでインフラコストを50％も削減したのか

2012年に設立された Navは、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。「スモールビジネスの成功率を上げていくこと。」そのミッションはここに凝縮される、とエンジニアリングディレクターのTravis Jeppsonは言います。

数年前、Navは自分たちの成功への道筋に、障害があることを認識しました。ビジネスが急速に成長し、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」と、Jeppsonは言います。「問題の大部分はスケールに関するものでした。私たちはそこにただお金を投入しようとしていました。『もっと多くのサーバーを稼働させよう。増えた負荷をさばくためにより多く作業しよう』といった具合に。私たちはスタートアップなので、そんなことをしていては終焉の一途をたどりかねませんし、そんなことにに使えるほどお金の余裕は我々にはないのです。」

こういったことに加えてすべての新サービスは違う10人を経由してリリースされなければならず、サービス立ち上げに2週間という受け入れがたいほどの時間をかけていたのです。パッチ管理とサーバ管理のすべてが手動で行われていたので、皆がそれらを見守り、うまく維持していく必要があったのです」とJeppsonは付け加えます。「非常にやっかいなシステムでした。」

Jeppsonは前職でコンテナを取り扱っていたため、Navの経営陣にこれらの問題の解決策としてこの技術を売り込みました。そして2017年初め彼の提案にゴーサインがでました。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、類似したリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました」と、彼は言います。

数多くのオーケストレーションソリューションを評価した結果、Navチームは AWSでのKubernetes 採用を決断しました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。一方でその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」

Jeppsonの4人編成のエンジニアリングサービスチームは、Kubernetesを立ち上げ、稼働させるのに6ヶ月かけました（クラスターを動かすために Kubespray を使いました）。そして、その後6ヶ月かけNavの25のマイクロサービスと一つのモノリシックな主要サービスのフルマイグレーションを完了させました。「すべて書き換えたり、止めることはできませんでした」と彼は言います。「稼働し、利用可能であり続けなければいけなかったですし、ダウンタイムがあってもをそれを最小にしなければなりませんでした。そのためパイプライン作成、メトリクスやロギングといったことについてよくわかるようになりました。さらにKubernetes自身についても習熟し、起動、アップグレード、サービス提供の仕方についてもわかるようになりました。そうして移行を少しずつ進めていきました。」

この過程で重要だったのは、Navの50人のエンジニアを教育すること、そしてマイグレーションに当たり新たなワークフローやロードマップについて透明性を確保することでした。 そこでJeppsonはエンジニアリングスタッフ全員に対し定期的なプレゼンテーションや、一週間にわたる1日4時間の実習の場を設けました。そして彼はすべての情報を置いておくために GitLabにリポジトリを作成しました。 「フロントエンドとバックエンドの開発者たち全員に、kubectlを用い、独力でnamespaceを作成し、取り扱う方法を見せていきました」と彼は言います。「いまや、彼らはやってきて『これは準備OKだ』というだけで済むことが多くなりました。GitLabの小さなボタンをクリックすれば本番環境にリリースできるようになっているので彼らはすぐに次の行動に移ることができます。」

マイグレーションが2018年初めに完了したあとの結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は1日あたり10だったものから50となり5倍増えました。そして同社はインフラコストを50％削減しています。「次はデータベース側に取り組みたいです。それができればかなりのコスト削減を継続できるでしょう」とJeppsonは言います。

また、KubernetesはNavのコンプライアンスのニーズにも力を貸しました。以前は、「1つのアプリケーションを1つのサーバーにマッピングする必要がありました。これは主にデータ周辺でコンプライアンスの異なるレギュレーションがあったためです」とJeppsonは言います。「KubernetesのAPIを用いれば、ネットワークポリシーを追加し、必要に応じてそれらのデータを分離し制限をかけることができるようになります。」同社は、クラスターを規制のないゾーンと、独自ノードセットを持ったデータ保護を行うべき規制ゾーンに分離しています。また、Twistlockツールを使用することでセキュリティを確保しています。「夜、よく眠れることもね」と彼は付け加えます。

Kubernetesが導入された中、Navチームは Prometheusを採用してシステムのメトリクスやロギングの改良も始めました。。「Prometheusは開発者にとって、とても採用しやすいメトリクスの標準を作ってくれました」とJeppsonは言います。「彼らには、何をしたいかを示し、したいことを実践し、そして彼らのコードベースをクリーンな状態に保つ自由があります。そして私たちにとってそれはまちがいなく必須事項でした。」

これから先を見据え、次にNavが意欲的に視野に入れているのは、トレーシング(Tracing)、ストレージ、そしてサービスメッシュです。そしてKubeConで多くの時間をいろんな企業との対話に費やしたその後で、現在彼らはEnvoy、 OpenTracing、そして Jaegerを検証しています。「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています」とJeppsonは言います。「クラウドネイティブなソリューションをフルに採用できるようになるには、スケーラビリティ面でやるべきことがまだたくさんあります。」

もちろん、すべてはKubernetesから始まります。Jeppsonのチームは、この技術でNavをスケール可能にするプラットフォームを構築しました。そして「これまで経験したことのない新たな自由、たくさんの価値をNavにもたらしてくれたのです。」と彼は言います。新製品を検討しようにも、隔離された環境を用意するのに6か月待たなければならず、その後もトラフィックが急上昇するのに対応するやりかたも考え出さなければならないという事実があり、身動きが取れなくなってしまっていました。「しかし、もうそういった話もなくなりました。」とJeppsonは言います。「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」