OpenStack Days Tokyo 2019 / CloudNative Days 2019 参加レポート (1)

はじめに

OpenStack や CloudNative (Container, Kubernetes, Serverless, etc.) に興味のある人たちが一堂に会する年に一度のイベント、"OpenStack Days Tokyo 2019", "CloudNative Days Tokyo 2019"に参加してきたので、レポート数回に分けてをまとめさせていただきます。

個人的な興味分野としては、膨大な永続データを扱う用途で Kubernetes (k8s) を使う場合に、どのようにアプリの設計・実装をするのか知りたかったので、このあたりを掘り下げられそうなお話を中心にまとめていきます。

資料のリンク

isaoshimizuさんが github に公開済み発表スライドの一覧をまとめられておりますので、きになる資料があればこちらを参照されると良いと思います。

プラットフォーム利用者の傾向

Keynoteセッションにて長谷川さんが紹介されていた(アンケート集計による)利用者の動向としては、次のような内訳となったとのことです。

1位. AWS
2位. GCP
3位. Azure

また、AWS と Private Cloud(OpenStack) の利用比率については 2:1 となっていました。
来場者は OpenStack に並々ならぬ関心がある人が多いはずなので、世の中の平均値については、AWS の比率がもっと高くなると考えられます。

K8s へのマイグレーション

セッション全体の傾向としては、既存のシステムをどのようにして k8s に載せ替えていくか、マイグレーション方法についての言及が多くなっており、参加者の興味が PoC から実際の導入段階に進みつつあることが伺えました。

AirBnB Performing Infrastructure Migrations at Scale

AirBnB の k8s への migration 事例については、他社にも適用ができるように内容が一般化されており、とても良い内容でした。発表内容については、2019年6月にて発表された内容とほぼ同一なので、次のビデオアーカイブでも内容を視聴出来ます。

• https://www.youtube.com/watch?v=QQ1QW4boM4Q

スライドの最後に要点がまとめられていたので、こちらをベースに主張されている内容をまとめました。Melanie Cebula さんは Migration を次のようにとてもユニークな視点で捉えていることが分かります。

• Refactoring ⊂ Migration
• Migration = アプリケーション側の機能変更を伴わない形で、システムに何らかの変更を加えること

Refactoring が Migration に含まれるということは、Migration の目的も Technical Debt(技術的負債)の返済となります。

また、次の言葉がとても腹落ちしました。

"Migrating is an explicit tradeoff of taking on overhead now to reduce worse overhead later"

Migration を今実施することで、技術的負債の要因となる将来のオーバーヘッドを減らすことができる。Migration をしなければ、時間経過と共にオーバーヘッドが積み上がっていく。
ということになると思います。
Migration を技術的負債の返済と捉えると、返済を先延ばしにすると状況がどんどん悪くなってしまうので、早めに返済した方が良い、ということになります。

ただし、今回の発表内容では Microservice化について触れられていませんので、次の発表動画を合わせて見ると良いと思います。

• https://www.youtube.com/watch?v=ytu3aUCwlSg&feature=youtu.be

Monolith から Microservice への Migration についても、ボトルネックを取り除くという意味では Refactoring の一つと捉えることができそうです。
k8s への Migration については、前提として Microservice へ移行が完了していないと、k8sのメリットは出てこないと思います。

10 Takeways

1. Identify migration type to determine overall complexity and risk
   Effort, Urgency, Scale の3軸で Migration の種別を把握することで、複雑さやリスクをを把握しましょう

2. Run frequent, efficient and tightly-scoped migrations
   高頻度、効率化、範囲を絞り込んだ Migration を実施しましょう

3. Sequence, prioritize, and parallelize migrations
   シーケンシャル、優先度の高いものからの実施、(非依存作業の)並列化を実施しましょう

4. Long-term planning, forecasting and stress-testing to avoid surprise migration
   突然の Migration が必要となる状況を避けるために、予め長期的な計画を立てておき、予測や十分なストレステストを済ませておきましょう

5. Make the new approach the default
   新しいやり方を標準にしましょう

6. Fully finish migrations to reduce tech debt
   技術的負債を減らすために、Migration を完全に完了させましょう

7. Develop abstractions over infrastructure
   インフラ(k8s)をそのまま使う代わりに抽象レイヤを作りましょう

8. Run migrations as code refactors
   コードのリファクタリングとして、Migration を実施しましょう

9. Run a migration program with a migration lifecycle
   ライフサイクルを伴う形で、Migration を実施しましょう

10. Iterate on your migration to ensure its fully validated, enabled and finished
    Migration が完全に検証され、有効化され、かつ完了されることが確実になるまで続けましょう

発表内容のメモ

• 技術的負債を返済するための一手段として、migration を捉えることができる
  • 時間が経過する毎に技術的負債は溜まっていき、migration により返済される
  • 未完了な migration が残り続けると、技術的負債がさらに悪い状況をもたらす
• 技術的負債の例
  • 開発速度の低下
  • CI build, Deploy 時間が遅い
  • 環境やバグ等の再現ができない
  • Resiliency の低下
  • スケールの上限に到達してしまう
  • ネットワークの問題が発生する
  • セキュリティホールがある
  • 言語やフレームワークのバージョンがとても古くなる
  • End of Life となるコンポーネントの存在
• migration の位置付けについては、3変数で捉えることができる
  • Effort
    • Low
      • Security Patch, OS Upgrade
    • High
      • VMs to Containers, orchestration の変更(k8s)
  • Urgency
    • Urgent
      • Security Patch, OS Upgrade
    • Discretionary
      • VMs to Containers, orcheatration の変更(k8s)
  • Scale
    • Low
      • Security Patch, OS Upgrade
    • High
      • VMS to Containers, orchestration の変更(k8s)
• migration の種別については、3つに分類できる。Infrastracture へ向かうに従い、複雑度とリスクが上昇する
  • Component
    • OS upgrade, Patch, Refactor
  • System
    • システムの移行
  • Infrastracture
    • クラウドへの移行、クラウド事業者の変更
    • コンテナ化
    • インフラの変更(chef to k8s 等)
• 移行シナリオとしては、Sequenced Migration が望ましい
  • 滅多に migration を実施していないシステムで migration を実施すると、結果として Cascading Migration にせざるを得なくなる
    • Cascading Migration シナリオになると、Migration に伴うリスクが上昇する
    • いわゆる、Cascading Failure のアナロジー を Migration に適用している
  • Non-cloud から k8s への migration を目指す場合、まずはクラウドへの移行を完了させて、High Availability である状態にした上で k8s に Migration するべき
• 非効率な Migration は、結果として Simultanious Migration を引き起こす
  • 例えば、Deployment Pipeline や CI System の Migration と k8s への Migration が同時進行してしまうと、それぞれの依存関係が新たに出来てしまう
• 依存関係の無い、小さな Migration を先に済ませた上で k8s への migration をするべき
  • AirBnB の例
    1. JVM を Upgrade し、コンテナ環境で正しく動作するようなリソース上限値等を設定しておく
    2. Service Discovery を、k8s を想定して動的に変わっても期待通りに動作するように改修しておく
    3. アプリのコンテナ対応を実施する
    4. k8s migration を実施する
• Migration に優先順位をつける (Prioritized Migration)
  • 今後の Migration について削減、あるいはシンプルに実施できるような施策を優先的にやる
    • 例: Ingrasttucture as code への Migration を先に実施した上で、コードの改修を進める
• Migrating is an explicit tradeoff of taking on overhead now to reduce worse overhead later
• Unfinished migrations make tech debt worse
• Migration に要する Overhead を可能なかぎり小さくするべき
  • AirBnB では、manifest file による k8s config 生成ツールを作成することで、k8s の設定を抽象化した
  • 開発者側はサービスの改善により多くの時間を使いたいので、Migration に要するコストを下げるツールが必要