クラウドネイティブの複雑さに向き合うあなたへ / If you are facing the complexity of Cloud Native

CloudNative Days Tokyo Committeeが主催するイベント CloudNative Days Tokyo 2021 で発表した「クラウドネイティブの複雑さに向き合うあなたへ」の登壇資料です。
https://event.cloudnativedays.jp/cndt2021/talks/1251

クラウドネイティブなアプローチを導入したシステムの構築にも慣れてきた頃。気がつけば存在している見知らぬリソース、増え続けるマイクロサービス、管理しきれないInfrastructure as Code、乱立するGitリポジトリ、動かないまま放置されたCI/CDパイプライン、誰も見ないモニタリングダッシュボード……。
変化し続けるビジネスニーズに応えられるような、変更に強いシステムを構築していたはずが、いつの間にか複雑なものになってしまったと感じているあなたへ。本セッションでは、クラウドネイティブな実践を続けていくために大切にすべきポイントについて考えていきます。

Transcript

1. クラウドネイティブの 複雑さに向き合うあなたへ 2021/11/5 CloudNative Days Tokyo 2021 TERAOKA Keisuke
2. 寺岡慶佑 (とばち) • クラスメソッド株式会社 ◦ ソリューションアーキテクト • 2021 APN AWS Top Engineer • 好きなAWSサービス ◦ AWS App Mesh ◦ Amazon EKS • 趣味 ◦ 紅茶、ビール 発表者紹介 @toda_kk
3. お話ししたいこと クラウドネイティブの複雑さ
4. LB かつてシンプルだった頃 DB App
5. LB かつてまだシンプルだった頃 DB App Queue Storage Function
6. LB やがて来る複雑さ DB App Queue Storage Function ？ ？
7. LB やがて来る複雑さ DB App Queue Storage Function ？ ？ App ？ ？
8. LB やがて来る複雑さ DB Queue Storage Function ？ ？ App ？ ？ ？ ？ ？ DB ？ ？ App LB App DB ？ App App ？ App ？ App
9. LB やがて来る複雑さ DB Queue Storage Function ？ ？ App ？ ？ ？ ？ ？ DB ？ ？ App LB App DB ？ App App ？ App ？ App
10. • オンプレでは難しかったことが、クラウドだと容易に実 現できる ◦ サーバーを追加する、サーバーのスペックを上げる • マネージドサービスやSaaSによってできることが増える ◦ アーキテクチャの幅が広がる ◦ 夢が広がる ↓ やりたいことを何も考えずにどんどん進めていくと システムの全体像は複雑化していく クラウド技術による効能
11. • 登場する技術要素が多くなり、リソースが散らばりがち になる？ ◦ クラウドベンダーが提供するマネージドサービス ◦ サードパーティのSaaS製品、OSSツール • 変更が容易な分、不要なリソースが増えやすい？ ◦ 作ったものを放置しておくと、リソースは増えていく一方になる ◦ 「作りっぱなし」はコストもかかる • 好き勝手にいろいろできちゃう？ ◦ アプリケーションとインフラの境界が曖昧になる ◦ チーム間の担当範囲が曖昧になる クラウド技術による複雑化？
12. • 登場する技術要素が多くなり、リソースが散らばりがち になる？ ◦ クラウドベンダーが提供するマネージドサービス ◦ サードパーティのSaaS製品、OSSツール • 変更が容易な分、不要なリソースが増えやすい？ ◦ 作ったものを放置しておくと、リソースは増えていく一方になる ◦ 「作りっぱなし」はコストもかかる • 好き勝手にいろいろできちゃう？ ◦ アプリケーションとインフラの境界が曖昧になる ◦ チーム間の担当範囲が曖昧になる クラウド技術による複雑化？
13. なぜ複雑になるのか？ ビジネスや組織の変化に システムが応えようとするから
14. • 現実は複雑 • 社会も複雑 • ビジネスも複雑 • システムも複雑 • 組織も複雑 • 人間関係も複雑 • 人間の心理も複雑 この世は複雑
15. クラウドネイティブの複雑さは 現実の複雑さを反映したもの
16. クラウドネイティブとは何か？ そもそも
17. クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブ リッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリ ケーションを構築および実行するための能力を組織にもたらします。 このアプロー チの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダブルイ ンフラストラクチャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現 します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトの ある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェ クトのエコシステムを育成・維持して、このパラダイムの採用を促進したいと考えて ます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利 用できるようにします。 https://github.com/cncf/toc/blob/main/DEFINITION.md クラウドネイティブの定義
18. クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブ リッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリ ケーションを構築および実行するための能力を組織にもたらします。 このアプロー チの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダブルイ ンフラストラクチャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現 します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトの ある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェ クトのエコシステムを育成・維持して、このパラダイムの採用を促進したいと考えて ます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利 用できるようにします。 https://github.com/cncf/toc/blob/main/DEFINITION.md クラウドネイティブの定義
19. クラウドネイティブとはベストプラクティスである クラウドなどを使う際のベストプラクティスを文言化したものが、クラウドネイティ ブだと思います。あくまでも、ベストプラクティスとしての属性を表現したもので す。それを達成するために、技術やコンセプト、考え方があります。これらについて は、現在とは別のものが、今後新たに出てくる可能性があります。 今のようにクラウドや新しい技術が出てきて、全てプログラマブルになって効率化で きる時代になりました。人間がやれば分・時間単位で掛かる処理が、コンピューター ではミリ秒、ナノ秒でできてしまいます。CNCFの定義による「スケーラブルな…… 能力」というのは、「人間の限界を超えて自動化していこうよ」と言っているのだと 思います。 ここで言いたいのは、「自らのビジネスの中でスケーラブルなものを作っていきま しょう」ということです。規模の大小問わず、現時点で自らのビジネスを最も効率よ く回す仕組みを、クラウドネイティブで作っていくという意識が大事です。 草間一人×青山真也 クラウドネイティブ対談(1) 「クラウドネイティブ」はどう誤解されているか https://atmarkit.itmedia.co.jp/ait/articles/1911/04/news001.html
20. • 定義: スケーラブルなアプリケーションを構築および実行 するための能力を組織にもたらす技術 • 具体的に何をすれば「クラウドネイティブ」になのか？ ◦ クラウドを使っていれば「クラウドネイティブ」なのか？ ◦ 「コンテナ、サービスメッシュ、マイクロサービス、イミューダ ブルインフラストラクチャ、および宣言型API」を使うことが重 要なのか？ • 自ら解釈することが必要になる クラウドネイティブとは何か？
21. なぜ 「スケーラブルなアプリケーション」が 必要なのか？
22. ビジネスと組織の変化に対応するため
23. 「スケーラブル」で重要なのは システムの可用性や効率性を向上させるだけでなく ビジネスや組織の変化に 容易に対応できるようになること ビジネスと組織の変化に対応する
24. • 単に「規模が大きい」ということではなく、拡張性が高 く、変化に強いということ • システムが変化に応えるためには、疎結合であることが 求められる ◦ テスト容易性、デプロイ独立性 ◦ デリバリーまでのリードタイムの短縮・高速化や、デリバリー頻 度の向上 「スケーラブルなアプリケーション」とは
25. クラウドネイティブの複雑さは 現実の複雑さを反映したもの (再掲)
26. • 導入する技術や作成するリソースの目的が曖昧 ◦ どんな課題を解決するものなのか？ ◦ • システムに対する責任の所在が曖昧 ◦ 課題を誰が解決すべきなのか？ ◦ • 導入による効果が曖昧 ◦ 課題を解決できているのか？ ◦ クラウドネイティブの複雑さはどこからやってくるのか
27. • 導入する技術や作成するリソースの目的が曖昧 ◦ どんな課題を解決するものなのか？ ◦ 技術選定やリソース作成の目的を明確にする • システムに対する責任の所在が曖昧 ◦ 課題を誰が解決すべきなのか？ ◦ チームにオーナーシップを持たせて責任の所在を明確にする • 導入による効果が曖昧 ◦ 課題を解決できているのか？ ◦ 導入による効果を計測し、具体的なアクションに落とし込む クラウドネイティブの複雑さに向き合う
28. • その技術やリソースが解決する課題を明確にする • 導入の経緯や背景を記録する • デザインドキュメントを作成する ◦ 【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず 書くドキュメント「Design Docs at Google」 ◦ 緩やかに死んでいくシステム 技術選定やリソース作成の目的を明確にする
29. • システムの境界とチームの境界を一致させる ◦ 必ずしもマイクロサービスアーキテクチャを採用する必要はない ◦ モノリスへの回帰も選択肢として検討する https://dev.classmethod.jp/articles/devio2021-microservices/ チームにオーナーシップを持たせる
30. • そのチームが必要なことに集中させる ◦ 権限制御によって、他チームのシステムは触れないようにする ▪ AWSアカウントやVPC ▪ KubernetesクラスターやNamespace ▪ Gitリポジトリ、CI/CDパイプライン ◦ セキュリティガードレールによる権限の境界により、チームの責 任の境界を明確にする ▪ やるべきこと／やらなくていいこと の範囲を明確にする チームにオーナーシップを持たせる
31. • 具体的な評価指標を作成し、計測する ◦ デリバリーを高速化したい → 1日あたりのデプロイ回数 ◦ 可用性を向上したい → LBの5xx系エラー率 • チームのパフォーマンスに関する4つの指標 ◦ コードのコミットから本番稼働までのリードタイム ◦ デプロイ頻度 ◦ 障害発生からの平均修復時間 ◦ デプロイに伴う変更失敗率 • 継続的に計測し、改善する Nicole Forsgren Ph.D, Gene Kim, Jez Humble『LeanとDevOpsの科学』(インプレス) 導入による効果を計測する
32. 継続的な改善を行う組織文化をつくる
33. • 組織やチームに属するメンバーの行為を規定する、目に 見えない何か ◦ 明文化された規則とは異なる、共有された信念や価値観 ◦ 明文化されたとしても、実際に体現できているか？ • 個人の行為が組織の文化をつくり、組織の文化が個人の 行為を規定する ◦ 個人の行為と組織の文化は、つくり／つくられる関係にある ◦ あなたが継続的な改善を行うことで、継続的な改善を行う組織文 化がつくられる 組織文化とは？
34. • 解決すべき課題を明確にし、記録する ◦ 他のメンバーにも共有できる形にする • 簡単なところから、少しずつ、改善を始める ◦ はじめから全ての課題を解決しようとしない！ • 効果を計測し、改善の結果を評価する ◦ 次の改善活動につなげる 継続的な改善を始めるために
35. Thank you!