全ては開発にフォーカスするために　Yahoo! JAPANが目指した次世代開発環境の裏側 Part2

開発に集中できるプラットフォーム

勝田：ふたたび変わりまして、Yahoo! JAPANの勝田です。このようにYahoo! JAPANで抱えていた課題をゼットラボ側に検討してもらい、KaaS及びアドオンを開発してもらいました。

それをYahoo! JAPANへ持ってきて、実際に運用して課題を解決しました。またクラウド環境の運用ノウハウを蓄積したり、自分たちの経験を世に共有することによって技術の力で社会への貢献を考えています。Yahoo! JAPANでの運用ということで、Yahoo! JAPAN内の豊富なプラットフォームも利用可能になります。

使いたい機能は、ここと接続することでいろいろ利用することも可能になります。ごちゃごちゃしていて申し訳ないのですが、ATHENZとかですと認証周りのアプリケーションで、Kubernetesのカンファレンスであるkubeconでも発表していて、先ほど言ったような社会への技術的な貢献もしていけていると思っています。

あとはCI／CDを使ったり。コンテナですと、ステート情報を自身で持つことは非推奨なので、RDBに移して。MySQLにつないだりといったことも簡単にできるようになっています。

ということで最初のほうにも書きました、これらの減らしたいと思っていた開発外作業がどうなったかを見直してみると、システムのアップデートをするようなリリースや脆弱性対応は、先ほどのCI／CDツールを使ったり、KaaSの機能で無停止に提供することが可能になりました。

スケールも、1つのコマンドを打つことで適切な状態に持っていったり。障害対応に関して言うと、なにかダウンしてしまってもエンジニアはなにもしなくていい、自動で復旧する状態になって、監視・可視化に関しても、共通部分に関してはアドオンで提供をしています。

これらの開発外作業をなくして、開発に集中できるプラットフォームを実現しました。

実際の利用例

ということで、こういったKaaSができあがりました。では、Yahoo! JAPANはこれを使ってどうなったのか。実際に先ほどの機能がどのように使われているのかを見ていこうと思います。

利用の例として1つ簡単な例で、リリースまでなにかモノを出そうとして……最初に場所を作って、なにかアプリケーションを開発して、それを世に出す、という3ステップで見ていこうと思います。

開発者が一番やりたい部分としては、この3ステップのうち真ん中の「アプリケーション開発」の部分です。1番と3番の「クラスタ作成」と「デプロイ」という、アプリケーションを動かす環境を作ったり、リリースしたりするという作業がどれだけ削減されているかというのを見てもらえればなと思います。

最初に、場所作りとしてのクラスタ作成です。

これはオンプレで、Kubernetesクラスタを作っている人はわかると思いますが、なかなか大変です。KaaSですと、createというコマンド1つ打つことによって、このセットが一気にできあがってきます。個数なんかはその設定によるのですが、こういったKubernetesクラスタのセットが1つできあがって、しかもプリインストールしているアドオンも同時に利用可能になります。ということで最初のクラスタ作成は、1つのコマンドで完了しました。

それではアプリケーションを作っていきましょう。

1番注力したい部分です。今回は簡単な例ということで、アクセスしたら「Hello world」と表示するだけのアプリケーションになっています。あと1つそれに付随して、コンテナとしてこのアプリケーションを稼働させるよという設定と、コンテナイメージ作成の処理も一緒に作っています。

これをアプリケーションエンジニアが開発しまして、利用可能な状態にしていくにはどうするのかというと、社内のGitHubに保存します。すると社内のCI／CDツールであるScrewdriverのパイプラインが自動で動いて、社内のコンテナイメージが利用可能なので、そのままDocker Registryに自動で上がるようになっています。

この図の矢印にあるように、右側の矢印は自動で行われますので、エンジニア側としてはこのファイルを保存するだけです。そのため、言ってしまえば開発して保存するだけで利用可能な状態ができあがります。

このあと公開作業をするのですが、その準備段階として3つの設定ファイルが必要になっています。どんな設定かというと、この作ったアプリケーションを「何個起動させますか」というコンテナ起動設定と、「どのようにバランシングをしますか」という負荷分散設定と、「どんな公開URLにしますか」といった紐付け設定ですね。これに関しては削減する方法についてお話します。

そういった3つの設定を作って、じゃあ実際のデプロイ作業です。

これはもうKubernetesを使ってる人ならわかると思うんですが、kubectlで1コマンドにすることによって、今用意したファイルを最初に作ったKubernetesクラスタに設定することによって、これだけでデプロイが完了となります。

ということでこの3ステップ、クラスタ作成・アプリケーション開発・デプロイ作業というものの、1番やりたいアプリケーション開発作業に注力できる。1番と3番に関しては1つのコマンドを打つだけで完了するというようなことが見えたかと思います。

効率化の効果

ほかにもいろんな効率化をしていったので、このサービスを運用した場合にどんな作業が出てくるか、それがどのように低減されるのかを見ていこうと思います。

まず、最初にすることは動作確認です。実際に世に出したサービスが稼働しているかを見てみましょう。今回はすごく簡単な、「Hello world」と表示するだけのアプリケーションです。

先ほど公開URLに設定したところにアクセスしてみると、「Hello world」と表示されました。

これを世に出すだけではだめで、安定した稼働を実現できるかを確認していきます。監視の可視化の部分ですね、そこでデフォルトで提供しているKubernetesのダッシュボードなどで、自分自身の作ったアプリケーション、コンテナが落ちてないか見たり、バランシング設定なども見れるようになっています。

あと、システム自体の状態として、Grafanaでの可視化も行っています。

システムのメトリクス情報を自由に設定することができて、デフォルトでもいくつかリリースをしています。必要なコンテナに関してはグラフで確認することができるようになっています。ここはユーザー側ではなにも意識する必要がなく開くことができるようになっていて、最初に作られたクラスタでURLが決まっていて、そこにアクセスすると見ることができるようになっています。

あとアラート設定をされていまして、最低限必要な監視はただクラスタを作るだけでアラーティングされます。アラートの通知先の設定は必要なのですが、そういった部分を設定すれば、最低限のアラーティングは提供されるようになっています。

このグラフを見ていたら、たくさんアクセスが来て、最初に作ったサイズでは耐えきれなくなった時にはスケール作業をしましょう。ということで、これを稼働させていると、nodeを追加して古いものは削除するという作業の必要がありますが、これも1つのコマンドで作業が完了します。

今回はworkerというコンテナを移動させる部分を増やしたいので「アップデートします」という1つのコマンドを打つだけで、このように適用値を増やすことができます。

これらも古い部分に関しては自動で削除されていて、しかもアップデート中にコンテナも生き続けますので、サービスを無停止でアップデートすることが可能になります。

このように無停止で稼働させるのですが、じゃあログを見てみたいという時に、古いログをコンテナ自身は持っていませんので確認できません。ですが周辺プラットフォームとしてSplunkを社内で持っていますので、そこにログが自動的に送信されています。これも利用者側はなにも意識する必要はないので、ただそこに作られたクラスタにコンテナを起動させることで、社内のSplunkに自動でログが送信されるようになっています。

そのため、最初にテストでやっていたものをあとからログで確認したいという時に、社内のSplunkシステムで検索することによって確認することができます。

あと、やはり必要になるのは脆弱性対応です。これもアップデートの1つなのですが、これは緊急度が高いアップデートだと思います。

先日もKubernetes自体の脆弱性としてCVE-2018-18264というのがあったのですが、これも無停止でアップデートできるということが強いです。なにかアップデートさせたいという時に、今回の脆弱性の対応バージョンである1.12.3を適用します、という1コマンドを打つことによって、それだけで完了することができます。

次世代開発環境の利用状況

こうしたさまざまな負担の軽減があります。そんな開発に注力できる、自動で運用トラブルをできるだけなくす技術が、どれだけYahoo! JAPAN内で使われているかを見ていこうと思います。

実はこのKaaSというのは、1年前のテックカンファレンスでも紹介しています。1年前ではまだまだ使われていなかったので、利用しているサービスもメインで活用しているのは1個だったり。そこで使われているクラスタ数もテスト用と本番用と、3～4個でした。

その後1年を経て、Yahoo! JAPAN内でもサービスの開発に注力したいと。できるだけ余計な作業は減らして、より安定したものを届けたいということで、KaaSはどんどん使われてきています。利用サービス数も、社内向けのものもふくめて50以上のサービスで稼働しています。

クラスタ数に関して、タイトルでは「100個」と書きましたが、その後どんどん増えて、現在は200何十個を超えました。これもYahoo! JAPAN内の……ほかの一般的な企業でどれくらいクラスタを利用されてるかわかりませんが、イメージとしてはサービスに対して、本番環境とステージングと開発用とで、だいたい3～4個なのかなと思っています。

やはりYahoo! JAPANはサービス数が多いので、その3～4個×50サービスで、200以上あります。これを管理していくことになります。

利用したチームにおける変化

これによって、Yahoo! JAPAN側の開発チームはいろいろな部分が効率化されました。個人的には1番いい部分って自動復旧なのかなと思っていたのですが、利用者の方に話を聞いてみると1番期待している部分としては、スケール作業ですね。これがユーザーに対していくつぐらい必要かを計算して適切な状態にするのは、人間がやらなければいけませんでした。

例えばこの日はなにかイベントがあってたくさんユーザーが増える時も、その不足の部分にコンテナを合わせてくれて、自動で上がってくれました。人間がそういった作業をしなくていいことで、開発に注力できるということが挙げられていました。

そういった管理作業がなくなって、少人数でも開発が可能になったので、より多くのサービスで人が開発に注力できるようになりました。

こういった50以上のサービスの運用はどこにいったのかというと、基本的にチーム自体は開発メンバーだけになって、運用は先ほどありましたが別の専門のチームで進めています。ここをどれくらいの人数でやっているのかというと、ここに50人、100人いたら「結局同じじゃん」ってなってしまいますが、やっているのは10人くらいです。

しかもその半分くらいはユーザーに、どうやったらうまく利用できるかという話をしているチームなので、実際に運用しているメンバーは10人を切る人数になります。

そんな50人、100人必要だった運用がどうやって効率化されているのかというと、1つは自動化です。先ほどの利用例でもありましたが、なにかしたい時に人が触るのは1コマンドだったり、もしくは自動でやってくれたり。そういう部分で、人がやる作業をできるだけ減らすことによって実現されています。

あと先ほどの利用例を振り返っていただくとわかる部分ですが、ユーザー側でなにかやりたいと思ったら、ユーザー側でコマンドを打つだけで完了しています。運用チーム側にはとくになにか「これをしてくれ」というものを挟まずに、やりたいことが完了まで持っていける。

そういうことで、管理チーム・運用チームというものは、リソース管理だったり提供しているアプリケーションの最新化をするだけで、実際に稼働しているKaaSは運用が可能になっています。

将来の展望

こういったKaaSはまだまだ新しく、より使いやすいように進化していこうとしています。途中でもありましたが、1コマンドで完了する部分だったり、余分な2～3ファイルを作ったりということがありましたが、それをできるだけなくしていこうと考えています。

右側に表示しているようなUIで、ポチポチ操作して作っていくことを想定しています。あまりはっきり見せられませんが、こういった画面で操作していくことによって実現して、Kubernetesの知識があまりなくても開発していけるようなKaaSを実現していこうとしています。

あと、ほかにやろうとしているのは、より使えるシーンというものを増やそうということです。例えばマシンラーニングであったりAIの開発であったり、たくさんの処理をするものに対してより高性能なクラスタも実現しようと考えています。Yahoo! JAPANですとやっぱり数100台とか1000台以上で稼働しているサービスもありますので、それも全部乗っけられるような大規模なクラスタも実現しようとしています。

またコンテナというのはやっぱりデータをその場で保持することが難しいので、今だとCluster外となる社内のMySQLなどに保存していたりしますが、Cluster内で見ていくほうが高速でやれたり、いろいろ自由度が高いのでステートフルなクラスタも実現しようと考えています。

まとめます。

開発に集中できる環境として、Kubernetes-as-a-Serviceを提供して、Yahoo! JAPANが元から持っている資産を有効活用できるオンプレのKubernetesクラスタの実現をしました。

そんなKaaSによって、運用者側の作業もすごく減らして、200を超えるクラスタであっても10人程度のチームで運用・管理ができるようになりました。これのキーワードとしては、自動化とユーザー完結という部分を話させていただきました。

本セッションの発表内容はここまでとなります。よりディープな部分を話したいという場合は、このあとご質問していただければと思います。今日はどうもありがとうございました。

（会場拍手）