[レポート] Cloud Native Challenges in Private Cloud with K8s, Knative #linedevday_report

Cloud Native Challenges in Private Cloud with K8s, Knative

2019年11月20日（水）・21日（木）にグランドニッコー東京 台場でLINEのデベロッパーカンファレンス「LINE DEVELOPER DAY 2019」が開催されました。

• LINE DEVELOPER DAY 2019

本記事は、セッション「Cloud Native Challenges in Private Cloud with K8s, Knative」をレポートします。

スピーカー

• 西脇 雄基 [LINE Verdaプラットフォーム開発チーム Manager]

セッション概要

LINEでは、2016年より2000を越えるLINEの開発者向けにPrivate Cloudを提供しています。我々のPrivate Cloudでは、VMサービスだけでなく、Managed Database Serviceなど様々なレイヤーのサービスを提供しています。最近は、ユーザのアプリケーション開発、運用の仕方もコンテナを積極的に取り入れたり、動的にクラウドリソースをプロビジョニングしたり少しづつ変わってきました。そういった背景もあり、我々Private Cloud開発チームでは、Managed Kubernetes Serviceの提供やFunction as a Serviceの提供も特に力を入れ始めています。こういった取り組みを通し、Private CloudでありながらもCloud Nativeなシステムを構築できるようにし、LINEの開発者がよりビジネスロジックの開発に集中できるようなPlatformを作り上げることを目指しています。本セッションでは、Managed Kubernetes Service、Function as a Serviceの２つのサービスについて、”何を提供しているのか””なぜ、それらのサービスをPrivate Cloudで提供するのか””どのように、それらのサービスをPrivate Cloudで提供しているのか””Managed Kubernetes Service, Function as a Serviceの先には、何があるのか”といったポイントで紹介します。

スライド

公開後、リンクします。

レポート

質問

• k8sをインストールしている人は？ : 結構いる
• k8sをプロダクション環境で使っている人は？ : 結構いる

概要

• 高品質なインフラリソースをオンデマンドで提供
• どのように開発者が開発しやすいものを作っているか紹介

自己紹介

• 2017年に入社
• IDaaSのプラグイン、コンポーネントの
• k8sチームに携わる
• OpenStack、k8sチームのまねーじゃー

Verdaの話

• 2つのIFを提供
  • Web API
  • Web UI
• インフラリソースをプロビジョニング、作成、削除ができる
• マネージドなk8sサービスなども提供している
• Private Cloudのユーザーはあまり細かく考えずにミドルウェアを使える
• コードをデプロイする仕組み、GUI上でイベントでファンクションを動かすようなものも提供している
• アプリ開発者がワークロードに合わせて使っている
• 35,000のリソース（VM）が動いている
  • その中。多くが直近1年に立ち上げられている（成長中）
  • 利用効率も背景には隠れている（過剰だったりしている）
    • k8sが一躍買ってくれると期待している

Cloud Nativeとは？

• CNCF Cloud Native Definition v1.0
  • クラウドネイティブ技術は、動的に操作可能であるスケーラブルな環境を支える技術である
  • システムは疎結合であることを支援する、管理性の向上や自動化によりインパクトの大きい変更も受け入れられる
  • → 状況に応じて動的に変わるシステムが目指す姿である
    • これを実現しようと取り組んでいる

何を解決したいか

• ベネフィット
  • アプリエンジニアの観点で、継続的デプロイができるようにすることでインフラ管理の煩雑なオペレーションから解放される
  • Private Cloudのエンジニアの観点では
    • インフラの抽象化が進む
    • 細かい調整、コミュニケーションが不要になる
  • 例 : Cloud Nativeではない環境
    • システムを作り始めでは、まずアプリケーションを開発しインフラをプロビジョニングを行う
    • その後、インフラ上にデプロイして運用していく
    • 現在、4,000のプロジェクトで回している
      • 社内用の改善のミニプロジェクトから、大規模なものまで
      • プロジェクトの携帯に問わず回すことになる
      • 思い思いにインフラリソースを管理することになる
        • 必要以上にインフラリソースが確保されることになる
        • 平均的な利用率は10%を下回っている
        • 利用効率が良いとは言えない
    • 継続的なデプロイをインフラチーム主導で進めることは難しい
      • アプリケーションがどのように運用されるかは、インフラチームの範囲外となってしまう
        • どのような動きをするのかを把握することが難しい
        • 最大のアクションは、お願いすることしかできない
  • Cloud Nativeな環境では
    • ヒントファイルを作り、置くことでどのように動いているかが把握できる
      • 例えば使用率の低いサーバーを移行したりすることができる
    • インフラチームという観点でも、インフラチームが主導的にアクションできるメリットがある
  • Diving
    • 2つ提供している
      • マネージドなクラスタ
      • Database as a Service (Managed Middleware)
      • Function as a Service
        • 自動化のプラットフォームとして
  • Managed k8s Missions
    • 3つある
      • HAであるk8s Clusterの提供
      • 継続的に安定して動かすこと
      • どのようなアプリを乗せるのか（ソリューションアーキテクト）
    • 背景は、もともとk8sを使おうとしていたチームを楽にする

Overview

• APIサーバーがManaged k8sのIFになる
  • ワーカーの追加リクエストなどを受け付ける
  • 細かいビジネスロジックは含まれない（RANCHERを利用）
• Add-on Manager
  • 追加で動かしたいMiddlewareを起動させるIF

Add-on Managerの機能とユーザービリティ

• Middlewareを使おうと思った場合は色々大変
• 動かすためのMiddlewareもマネージする
• 例えばログを一箇所にまとめたくなった場合、ログを集めるために必要なMiddlewareを導入する

RANCHERによる自動化

• 1API Callで復元可能
• 自動化を進めることで運用にかけるリソースを最小限に留められている

モニタリング機能

• 非常に重要
• 2種類を提供
  • ヘルスチェック
    • 各機能が動いているかどうか
    • 管理用のエージェントから死活監視
  • プロメテウスによるメトリクスモニタリング

Current Scale vs Operators

• 10月にプロダクションリリースしてから、着々と増えている
• 増えてくると予想している

ロードマップ

• Done
  • HAであるk8s Clusterの提供
  • 継続的に安定して動かすこと
  • どのようなアプリを乗せるのか（ソリューションアーキテクト）
• TODOs
  • Add-onのサポート

k8s で何を提供するのか？

• FaaSを提供するモチベーションとは？
• オペレーションでは、実際、デプロイ以外にも様々なことをやっている
  • アラート監視
  • 何か特定の処理を実施したい
  • バグチケットの作成
  • 毎時実行する何か
• 開発コストも地味にかかる
• そのためにFaaSを作っている
• 概念
  • Event Provider : 適切なタイミングで適切なイベントを発火する
  • Function Service : イベントを全部集めて紐づけられていたらInvokeする
• API, Controller
  • リクエスト通りのリソースを作るのが責任範囲
  • Functionをデプロイしたりする
• Kntiveが動いている
  • Googleが出したOSS
  • buildingではソースコードを元にコンテナの作成を行う
  • servingで素のFunctionがでデプロイ
• istio-ingressgatewayとKnativeのservingが連携して動いている
• Event Providers
  • OpenStack -> Raddit MQ -> kafka

ロードマップ

• DONE
  • シンプルなファンクションを実行
  • VMの作成や削除などのイベント発火
  • Cron的なイベント発火
  • HTTPイベント発火
• TODOs
  • もっと多くのイベントのサポート
  • パイプライン
  • ファンクションの細かな制御のリッチコントロール

Future of LINE Cloud Native

• 導入フェーズ。導入するための活動をしている
• 広まってきた後はインフラ効率をどうやって上げられるか考えている
• インフラ利用効率をあげるには？
  • ショートタームでは
    • FaaSもk8sクラスタになっている
    • k8sクラスタをユーザーに提供している状態
    • 自動的なスケールイン、スケールアウトを実装
    • 利用Usageに合わせてインフラ利用効率を上げられるのではと考えている
  • ロングタームでは
    • 課題
      • スケールイン・アウトに時間がかかる懸念がある
      • 仮想化のオーバーヘッドが残っている課題がある
    • 複数のk8sが強調したり、1つ大きくなったりするかもしれない
    • k8sのアップストリームを見ながら改善したい

まとめ

情報量が多く、Verdaプラットフォームでの様々な取り組みが聞けて非常に楽しく勉強になるセッションでした。

k8sを使ってFaaSを作り提供する。めちゃめちゃ楽しそうですね。

社内向けにk8sを使おうと考えられている方は非常に参考になると思いますので、ぜひぜひ参考にしましょう！