導入から3年が経過したプライベートクラウドの今
西脇雄基氏：こんにちは。LINEのプライベートクラウドのプラットフォーム開発チームでマネージャーをしている、西脇と申します。
まずはじめに、会場のみなさんがKubernetesを使っているのか、どのくらいの方が知っているのかを把握しておきたいので、Kubernetesを今までインストールしたことがある方、手を挙げていただけますか？
（会場挙手）
思ったよりも多いですね。では、今プロダクションで使っている方、手を挙げてください。
（会場挙手）
思ったよりたくさんいらっしゃいますね。わかりました、ありがとうございます。本日はKubeConも開催されているなか、LINE DEV DAYにお越しいただき、ありがとうございます。
LINEでプライベートクラウドの導入を開始してから、もうすぐ3年が経とうとしています。この3年間、プライベートクラウドとしてスケールの課題やパフォーマンスの課題、またはプライベートクラウドとしての責任範囲を、インフラリソースをただプロビジョニングするだけではなくて、もうちょっと高いレイヤーまでカバーしようなどといった、さまざまなチャレンジがありました。
我々プラットフォーム開発チームの観点では、当初は高品質なインフラリソースをオンデマンドで提供しようという目標を掲げていましたが、最近ではインフラレイヤーに留まらず、開発者が開発しやすい環境の整備という方向性に向かって、日々クラウドの改善を実施しています。
本日は、開発者が開発しやすい環境づくりをどのように進めているか、それをCloud Native Challengeと称してご紹介させていただきたいと思います。
はじめに、本日スピーカーを務めさせていただく私、西脇のバックグラウンドを簡単にご紹介させていただきたいと思います。
私は2017年の12月にLINEに入社をしました。入社してから半年ほど、OpenStackと呼ばれるIaaS基盤構築ソフトウェアのネットワークプラグインの開発や、そのほかコンポーネントのカスタマイゼーションやバグフィックスを担当したのち、Managed Kubernetesチームの立ち上げと企画開発に携わっておりました。
現在は、Function as a Serviceの企画・開発をしながら、Managed KubernetesチームとOpenStackのチーム、両方のマネージャーをしております。
本題に入る前に、我々が提供しているプライベートクラウド「Verda」の全体像についてお話しさせていただければと思います。
この1年で2万VM増加
我々のプライベートクラウドでは現在2つのインターフェースを提供しています。1つがWeb API、もう1つがWeb UIです。
これらWeb APIやWeb UIを通して、ユーザーはロードバランサーやバーチャルマシン、ベアメタルサーバなどのインフラリソースを作成・削除できます。
また、これらIaaSレイヤーのリソースだけではなく、それらを活用したマネージドなKubernetesサービスやマネージドなデータベースサービスなど、マネージドなミドルウェアサービスも提供しております。これを提供することで、プライベートクラウドのユーザーは、ミドルウェアの詳細な設定やチューニング、または壊れたときの対応についてもあまり細かく考えずにミドルウェアを利用することできます。
また、最近とくに力を入れているのが、これらマネージドなミドルウェアとマネージドなインフラリソースを活用した、コードをリポジトリにPushしたら裏側でアプリケーションがデプロイされるような仕組みであったり、GUI上で任意のイベントに対してFunctionを登録することで、任意のイベントで実行されるFunctionを動かすことができるようなサービスなど、PaaSレイヤーのサービスも現在提供しております。
現在、このような複数のレイヤーのサービスをアプリケーション開発者の方がアプリケーションのワークロードに合わせて利用しています。。
また、スケールに目を向けてみると、現在3万5,000のVMがプライベートクラウドのリソースとして管理されています。この3万5,000という数だけを見ると、もしかしたら思ったより小さいと思われる方もいらっしゃるかもしれません。
ただ、直近1年に目を向けてみると、この中の2万VMが直近1年で作られていることからして、今後も、プライベートクラウドへのマイグレーションだったり、プライベートクラウドがどんどん活発に使われていっていることがわかるかと思います。そのため、我々もプライベートクラウドとして管理していくリソースはこれからももっともっと増えるだろうと予測しています。
ただ、のちほどまたご紹介したいとは思うのですが、実はこの数字の裏側には、サーバ数の増加に伴い、サーバのリソースをきちんと有効活用できていないという利用効率・使用効率の課題も隠れています。私たちはインフラリソースの有効活用化、利用効率を上げていくという部分にも、実はCloud Nativeというソリューションは一役買ってくれるのではないかと考えております。
Cloud Nativeを定義する4つのキーワード
では、本日タイトルにもしていますが、Cloud Nativeとは実際どんなもので、我々はどのように解釈しているのかについてお話をさせていただきたいと思います。
先ほどアンケートを取ってみたところ、Kubernetesを実際に使われている方、もうすでにインストールされている方があまりにも多かったので、おそらくここはみなさんもう目を通したことがあるかもしれませんが、もう一度僕のほうから我々の解釈という意味でご紹介させていただきたいと思います。
「Cloud Native」という言葉はCloud Native Computing Foundationという組織で定義されています。この中で私が重要な要素だと思っているところに、今、赤線を2箇所引いています。
1つ目の赤線には「Cloud Native技術は、クラウド、例えばハイブリッドクラウドやプライベートクラウド・パブリッククラウドなどの動的にインフラリソースを操作可能な環境を活用して、スケーラブルなアプリケーションの構築を支える技術である」と書かれています。
こちらには、重要なキーワードが2つ隠れていると思っています。1つが「スケーラブルなアプリケーション」。もう1つが「動的に操作可能である」こと。この2つがここで重要だと考えているキーワードです。
また、2つ目の赤線には「Cloud Native技術は、システムが疎結合で構成されることを支援し、管理性が増します」と書かれております。また、「さらには、自動化の仕組みと組み合わせることで、インパクトの大きい変更を頻繁に実施することができる」と。
こちらからは、少しコンテキストがズレてしまうかもしれませんが、私は「管理性の向上」と「自動化」をキーワードとして強調したいと思います。
私はこれら「スケーラブルなアプリケーション」や「動的に操作可能である」ということ、また「管理性の向上」や「自動化」という4つのキーワードをどんどん突き詰めて解釈をしていくと、Cloud Nativeは、状況に応じて自律的に変更可能なシステムを実現することを可能にし、それを実現していくことが我々のミッションだと考えています。
例えば、システムのキャパシティが足りていない場合はシステムが自動的にスケールアウトしたり、システムのアップグレード時はシステムに影響が出ないように自動的に実施されて、失敗時には自動的にロールバックがなされるなど、こういったことを実現するための技術がCloud Nativeであると考えております。また、これを我々のプライベートクラウド上で実現しようと現在取り組んでおります。
インフラの抽象化で、インフラエンジニアが恩恵を受ける
では、我々はこれらのCloud Native技術で何を解決したくて、なぜ取り組んでいるのかという部分をご紹介させていただきたいと思います。2つの観点でCloud Native化のメリットやモチベーションを紹介させていただきます。
1つ目は、明らかだと思います。アプリケーションエンジニアの観点で、アプリケーション開発者が開発に集中できるようにし、継続的なデプロイメントをできるようにしてあげることです。それを可能にしたことで、インフラ管理の煩雑なオペレーションや、「どのようにインフラを構築するか？」といった考慮から解放されます。これはよく言われていることだと思うのであまり違和感はないかと思います。
ただ、今回我々が強調したいのは、2つ目の、プライベートクラウド・インフラエンジニアの観点でのメリットです。パブリッククラウドを活用しているとあまり気づきづらいのですが、Cloud Native化を進めることで、インフラの抽象化が進みます。
インフラの抽象化が進むと、インフラリソースに対するオペレーションを、我々インフラチームがアプリケーションエンジニアと細かい調整やコミュニケーションをあまりせずに実施できます。
インフラの構築・運用サイクル
これについてはイメージしづらいと思うので、もう少し具体的に、インフラの利用効率を上げていくことを題材にご紹介したいと思います。
まず、Cloud Nativeでない環境、具体的にはバーチャルマシンやベアメタルサーバーをアプリケーション開発者の人たちがプライベートクラウドのAPIを通して構築をして、アプリケーションを開発して提供するというモデルで、そういった環境でのサービス開発のステップを4つのステップに分けてみました。
はじめに、一番上のApplication Developmentに注目をしてください。サービス開発の始まりは、おそらく要件やSystem Requirementなどが固まったあと実際に開発をするときに最初にするのは、アプリケーションの開発やコーディングがほとんどだと思います。
その後開発が終わると、開発したアプリケーションをデプロイしなければいけません。そのために、プライベートクラウドを使っている場合はAPIを通して、インフラのリソースをプロビジョニングすることになるかと思います。
インフラリソースのプロビジョニングを終えると、今度は作成されたインフラリソースに対してアプリケーションやスクリプトなどを実際インフラリソース上に展開、デプロイをすることになると思います。その後、デプロイしたシステムを運用していきます。
また追加の要件があれば追加でシステムを開発して、もしその追加開発の要件によって発生した開発物が新たにインフラリソースが必要であれば、またプロビジョニングをしていく。こういったサイクルを回すことになるかと思います。
現在我々のプライベートクラウド上では、開発環境なども含めて4,000を超えるプロジェクトでこのようなサイクルを回しています。もちろんこの4,000という数字は、1つのプロジェクトが1つのサービスに紐付いているかというと、そうではありません。
例えば社内用の改善のミニプロジェクトや、大きいシステムをいくつかのプロジェクトに分けているケースもあるとは思います。しかし、プロジェクトの形態を問わず、基本的にはこのようなサイクルを回すことになるかと思います。
サーバCPUの平均利用率は10％以下に
このようなサイクルを各プロジェクトが独立して回していった結果、各プロジェクトは思い思いにインフラリソースを確保することになります。
例えば、あるプロジェクトでは複数のバッチ処理を走らせないといけません。cronのために複数のサーバを確保しておいて、各サーバはcronの設定だけをしています。
また、ほかにもとあるシステムでなにか障害が起きたときには復旧用のスクリプトを流さないといけません。復旧用のスクリプトの実行ログを残すため、またスクリプトの実行環境の関係で、それを動かすためだけ、またはオペレーションのスクリプトを共有するためだけの目的、でサーバを確保しているプロジェクトもあります。
また、週末の特定の負荷に備えるために必要以上にあらかじめサーバを確保したり、各プロジェクトが独立してインフラリソースの構築というフェーズを実施しているため、プライベートクラウド全体で見ると必要以上にインフラリソースが確保されてしまう傾向が多くなってしまいました。
その結果、LINEの60パーセント以上のサーバのCPUのusage、平均的な利用率は、実は10パーセントを下回っています。
もちろんCPU以外のメモリやディスクなどのリソースも無視することはできませんが、CPUの数字だけを見ても、我々の今のインフラの利用効率はとてもいいとは言えません。
この結果を我々かなり重く受け止めていて、これを改善するために社内でプロジェクトを始めようという動きもありました。
ただ、実はこのNon-Cloud Nativeな構図、いわゆるVMやベアメタルサーバーをアプリケーション開発者が自身でAPIを通して作成をして、その上でアプリケーションをデプロイするというこの構図では、実はこういった課題に対してインフラチーム主導で取り組むのが難しいです。
なぜかというと、この構図では、我々プライベートクラウドチームのレスポンシビリティは、APIを通してリクエストが来たときに、そこに対して迅速にリソースを提供するのが我々のレスポンシビリティです。その後、提供したリソースの上でどのようにアプリケーションがデプロイされていて、アプリケーションが運用されていくのかは完全に僕たちの責任外になってしまいます。
なので、たとえ僕たちがいくつかのサーバで「ふだんぜんぜん使われていないんじゃないかな？」と思ったものを見つけたとしても、実際にはその上でどんなアプリケーションが動いていて、どういうスクリプトが何のために動いているのかも、僕ら側で把握することが難しいです。
なので、僕らが利用効率の問題に対してとれる最大のアクションは、我々がアプリケーション開発者に「すみません。これを移動させてください」というお願いをすることしかできないのです。
Cloud Nativeがインフラリソースの効率化にもたらす効果
では、この課題に対してCloud Nativeなシステムではどのように取り組めるのでしょうか？
まず、今までVMやベアメタルサーバーをオンデマンドに提供することだけをインフラチームのレスポンシビリティとしていたところを、Cloud Nativeなシステムではアプリケーションのデプロイやオペレーションまで責任範囲を広げていきます。
もちろんデプロイやオペレーションはプライベートクラウド側だけで完結するのは難しく、アプリケーション開発者・プライベートクラウドの両者が責任を持ち歩み寄って進めていくことが大事です。
具体的にこれがどんな影響を与えるのか、デプロイメントを例にご紹介したいと思います。
Cloud Nativeなシステムでは、アプリケーション開発者は、直接サーバを作成をしてどのサーバに対してどういったアプリケーションを動かすのか、開発者自身は考慮しません。
その代わりに、デプロイが必要なアプリケーションやスクリプト、システムに必要なソフトウェアを記述したヒントファイルみたいなものを、プライベートクラウド側で管理しているオーケストレーターに渡してあげます。その後、そのオーケストレーターがどのサーバに対してどのようなワークロードを動かすのかを判断してデプロイを実施しています。
こうすると何がうれしいかというと、我々プライベートクラウドのエンジニア側でどういったサーバが作られていて・どのサーバで・どういうワークロードが動いているのかが一目瞭然になります。
こうすると、オーケストレーター側がデプロイについて責任を持っているので、ユーザーが定義した「このソフトウェアとこのスクリプトがこのように動いていないといけません」という状況を保ちながら、我々インフラチームがインフラリソースの操作の実施を、アプリケーション開発者とのリアルタイムなコミュニケーションをなるべくせずに実施できるようになります。
そのため、例えば使用率の低いサーバを発見した場合、該当のサーバ上のワークロードを別のサーバに移動させて、サーバを返却するオペレーションも可能になります。
このように、Cloud Native化を進めることは、実はアプリケーションエンジニアの観点だけではなく、インフラチームの観点でも、インフラリソースの効率化という課題に対してインフラチームが主導的に取り組むことを可能にするという大きな意味があります。なので、そういった観点でも、我々は現在Cloud Native化を進めようと活動を行っております。
