KubeCon + CloudNativeCon North America 2019 参加レポート -Day 2, Day 3編-
砂川 辰徳
じゃらんnetを担当している砂川です。
2019/11/18 - 2019/11/21 にサンディエゴで開催された KubeCon + CloudNativeCon North America 2019 に参加してきました。
本記事では、後編としてDay 2とDay 3の様子を振り返りつつ、注目したセッションについて紹介します。
前編はこちらになりますので、合わせてお読みください。
参加動機
私のチームでは、コンテナアプリケーションのコンピューティングとしてAWS Fargateを採用しており、Kubernetesの運用経験はまだありません。しかし、今後の新規開発や既存環境のリファクタリング検討時に、Kubernetesは間違いなく候補にあがると予想されるため、キャッチアップを目的として参加いたしました。特に、
- Kubernetesの採用で得られるメリットは何か
- いかに既存組織にKubernetesを適用していくか
という問いに良い示唆が得られると良いなと考え、実際聴講したセッションも技術的に深堀った内容よりも導入事例が多かったです。
ハイライト
Day 2
Day 1のキーノートではCNCFのプロジェクトのアップデート関連の話題が中心でしたが、 Day 2では、Kubernetesのユースケースの動向に関する話題が中心でした。
特に印象に残ったキーノートはこちらです。
発表資料 より引用
このセッションでは2020年以降より多くの適用事例が出てくるであろうトピックとして、
- マルチクラウド/ハイブリッド構成
- 急激なトラフィック増加への効率的なスケーリング
- データベースなどのリソースも含めた管理への拡張
の3つをあげ、先行する事例をそれぞれに紹介していました。
2番目の事例で挙げられていたSpotify社の 10,000,000 requests / sec という数字はインパクトが強かったです。 上記トピックは他のセッションでもよく登場し、マルチクラスタ構成に関するセッションや、Day 1のキーノートで取り上げられていたVitessを中心にデータベース/ストレージリソース関連のセッションが多数ありました。
Day 2の最後ではカンファレンス会場周辺の街の区画を貸し切ったパーティーが開催され、あいにくの雨にも関わらず盛り上がっておりました。
Day 3
Day 3では以下のキーノートが特に面白かったです。
KubernetesがRuby on Railsから学べることは何か?という問いを切り口にしたユニークな内容でした。Ruby on Railsの有名な設計思想の1つである、「Convention over Configuration(設定より規約)」をKubernetesに適用するとどうなるか?というデモを通して、 Kubernetesは複雑であるが、その複雑性は必要性のある複雑さである と指摘していました。
その上で、
- Kubernetesの利用は手段であり目的ではない
- 開発者が本来の目的に注力できるように、Kubernetesを簡単に利用できる別のレイヤーのツールが求められる
と述べており、とても共感できる内容でした。
Day 3ではスポンサーブースもいろいろ周りました。
スポンサーブースの様子
AWSのブースでAWS App Meshの話を聞いていたら、Weaveworksが提供しているハンズオンを紹介されました。
を用いてGitOpsとCanary Releaseを手軽に体験できる内容となっており、とても良かったです。 ハンズオン資料は公開されていますので、ぜひお試しください。
特に印象に残ったセッション
多くのセッションに参加し、どれも興味深い内容でしたが、印象に残ったセッションを1つあげるとするとこちらです。
このセッションは、Kubernetesを既存組織に適用する場合、どのように推進していくべきか?というテーマでした。AirbnbがKubernetesを大規模組織に適用する事例が注目を集めたように、Kubernetesを既存組織にどう適用していくかは大きな関心事の1つとなっているようです。
Kubernetesによりマイクロサービスの運用管理コストは下がることが期待できる一方で、先程のキーノートの事例でも述べられていたように、Kubernetes自体は多機能で覚えることの多いプロダクトであるという事実があります。そのため、アプリケーション開発チームがビジネスロジックに集中するためには、Kubernetesをプラットフォームとして提供し利用してもらうという形で導入するのが有効な手段となりそうです。
発表者はプラットフォームとしてのKubernetesについて以下のように述べていました。
- Kubernetes自体だけではプラットフォームとは言えない
- プラットフォームとして機能するためには、アプリケーション開発チームが簡単に正しく使える必要がある
- そのためにはプラットフォームチームを組織し、導入のサポート・ツールの提供をしていくのが有効だ
一方で、プラットフォームチームを組織することによる注意点も指摘しています。ナイーブに推進してしまうと、「DevとOpsが分かれていたことによる諸問題をDevOpsとして統合し解決していく」という流れに逆行してしまいます。
そうならないためにプラットフォームチーム(≒Ops)はどうすべきかについて、少々私の解釈も含んでいますが、以下のような内容を述べていました。
Cognitive Loadを評価する
プラットフォームチームは、アプリケーション開発チームのCognitive Loadを計測し、その負荷を下げることを目的として活動する。
※Cognitive Loadは翻訳が難しかったのですが、何かを理解したり実行したりするときに伴う心理的な負荷という理解をしています。
組織のコンテキストに合う形でプラットフォームを定義する
初期はアプリケーション開発チームと一緒にプラットフォームのあり方を検討し、改善を繰り返し行いながら、自組織に合う型を定義していく。 成熟期は、提供している環境/ツールについてのドキュメンテーションを充実させ、ブラックボックス化を防いでいく。
アプリケーション開発チームに寄り添う
DevとOpsが分かれている状態に逆戻りしないために、チーム間の関わり方を成熟度に合わせて変化させながら寄り添う。
本セッションの内容は、Kubernetesに限らず影響範囲の大きい技術を導入する際にも参考になりそうで、とても良い示唆を得ました。
おわりに
最後になりますが、上記で紹介したセッション以外で、おもしろかったセッションを箇条書きにしておきます。
- How the Department of Defense Moved to Kubernetes and Istio - Nicolas Chaillan, Department of Defense アメリカ国防総省の導入事例
- Did Kubernetes Make My p95s Worse? - Jian Cheung & Stephen Chan, Airbnb Kubernetesを導入してパフォーマンスが悪くなってしまったケースの検証と対応について
- Moving from Legacy Infrastructure to the Cloud in a Government Organization - Chris Carty 自治体(カナダ オタワ市)での導入事例
- The Myth of the Monocluster - Matt Silverlock, Google マルチクラスタのメリットとデメリットについて
ほとんどのセッションの資料は、こちらの各詳細ページに公開されています。また、YouTubeにもセッション動画の再生リストが公開されています。ぜひ視聴してみてください。