Slide 1

Slide 1 text

クラウドネイティブの 複雑さに向き合うあなたへ 2021/11/5 CloudNative Days Tokyo 2021 TERAOKA Keisuke

Slide 2

Slide 2 text

寺岡慶佑 (とばち) ● クラスメソッド株式会社 ○ ソリューションアーキテクト ● 2021 APN AWS Top Engineer ● 好きなAWSサービス ○ AWS App Mesh ○ Amazon EKS ● 趣味 ○ 紅茶、ビール 発表者紹介 @toda_kk

Slide 3

Slide 3 text

お話ししたいこと クラウドネイティブの複雑さ

Slide 4

Slide 4 text

LB かつてシンプルだった頃 DB App

Slide 5

Slide 5 text

LB かつてまだシンプルだった頃 DB App Queue Storage Function

Slide 6

Slide 6 text

LB やがて来る複雑さ DB App Queue Storage Function ? ?

Slide 7

Slide 7 text

LB やがて来る複雑さ DB App Queue Storage Function ? ? App ? ?

Slide 8

Slide 8 text

LB やがて来る複雑さ DB Queue Storage Function ? ? App ? ? ? ? ? DB ? ? App LB App DB ? App App ? App ? App

Slide 9

Slide 9 text

LB やがて来る複雑さ DB Queue Storage Function ? ? App ? ? ? ? ? DB ? ? App LB App DB ? App App ? App ? App

Slide 10

Slide 10 text

● オンプレでは難しかったことが、クラウドだと容易に実 現できる ○ サーバーを追加する、サーバーのスペックを上げる ● マネージドサービスやSaaSによってできることが増える ○ アーキテクチャの幅が広がる ○ 夢が広がる ↓ やりたいことを何も考えずにどんどん進めていくと システムの全体像は複雑化していく クラウド技術による効能

Slide 11

Slide 11 text

● 登場する技術要素が多くなり、リソースが散らばりがち になる? ○ クラウドベンダーが提供するマネージドサービス ○ サードパーティのSaaS製品、OSSツール ● 変更が容易な分、不要なリソースが増えやすい? ○ 作ったものを放置しておくと、リソースは増えていく一方になる ○ 「作りっぱなし」はコストもかかる ● 好き勝手にいろいろできちゃう? ○ アプリケーションとインフラの境界が曖昧になる ○ チーム間の担当範囲が曖昧になる クラウド技術による複雑化?

Slide 12

Slide 12 text

● 登場する技術要素が多くなり、リソースが散らばりがち になる? ○ クラウドベンダーが提供するマネージドサービス ○ サードパーティのSaaS製品、OSSツール ● 変更が容易な分、不要なリソースが増えやすい? ○ 作ったものを放置しておくと、リソースは増えていく一方になる ○ 「作りっぱなし」はコストもかかる ● 好き勝手にいろいろできちゃう? ○ アプリケーションとインフラの境界が曖昧になる ○ チーム間の担当範囲が曖昧になる クラウド技術による複雑化?

Slide 13

Slide 13 text

なぜ複雑になるのか? ビジネスや組織の変化に システムが応えようとするから

Slide 14

Slide 14 text

● 現実は複雑 ● 社会も複雑 ● ビジネスも複雑 ● システムも複雑 ● 組織も複雑 ● 人間関係も複雑 ● 人間の心理も複雑 この世は複雑

Slide 15

Slide 15 text

クラウドネイティブの複雑さは 現実の複雑さを反映したもの

Slide 16

Slide 16 text

クラウドネイティブとは何か? そもそも

Slide 17

Slide 17 text

クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブ リッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリ ケーションを構築および実行するための能力を組織にもたらします。 このアプロー チの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダブルイ ンフラストラクチャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現 します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトの ある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェ クトのエコシステムを育成・維持して、このパラダイムの採用を促進したいと考えて ます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利 用できるようにします。 https://github.com/cncf/toc/blob/main/DEFINITION.md クラウドネイティブの定義

Slide 18

Slide 18 text

クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブ リッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリ ケーションを構築および実行するための能力を組織にもたらします。 このアプロー チの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダブルイ ンフラストラクチャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現 します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトの ある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェ クトのエコシステムを育成・維持して、このパラダイムの採用を促進したいと考えて ます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利 用できるようにします。 https://github.com/cncf/toc/blob/main/DEFINITION.md クラウドネイティブの定義

Slide 19

Slide 19 text

クラウドネイティブとはベストプラクティスである クラウドなどを使う際のベストプラクティスを文言化したものが、クラウドネイティ ブだと思います。あくまでも、ベストプラクティスとしての属性を表現したもので す。それを達成するために、技術やコンセプト、考え方があります。これらについて は、現在とは別のものが、今後新たに出てくる可能性があります。 今のようにクラウドや新しい技術が出てきて、全てプログラマブルになって効率化で きる時代になりました。人間がやれば分・時間単位で掛かる処理が、コンピューター ではミリ秒、ナノ秒でできてしまいます。CNCFの定義による「スケーラブルな…… 能力」というのは、「人間の限界を超えて自動化していこうよ」と言っているのだと 思います。 ここで言いたいのは、「自らのビジネスの中でスケーラブルなものを作っていきま しょう」ということです。規模の大小問わず、現時点で自らのビジネスを最も効率よ く回す仕組みを、クラウドネイティブで作っていくという意識が大事です。 草間一人×青山真也 クラウドネイティブ対談(1) 「クラウドネイティブ」はどう誤解されているか https://atmarkit.itmedia.co.jp/ait/articles/1911/04/news001.html

Slide 20

Slide 20 text

● 定義: スケーラブルなアプリケーションを構築および実行 するための能力を組織にもたらす技術 ● 具体的に何をすれば「クラウドネイティブ」になのか? ○ クラウドを使っていれば「クラウドネイティブ」なのか? ○ 「コンテナ、サービスメッシュ、マイクロサービス、イミューダ ブルインフラストラクチャ、および宣言型API」を使うことが重 要なのか? ● 自ら解釈することが必要になる クラウドネイティブとは何か?

Slide 21

Slide 21 text

なぜ 「スケーラブルなアプリケーション」が 必要なのか?

Slide 22

Slide 22 text

ビジネスと組織の変化に対応するため

Slide 23

Slide 23 text

「スケーラブル」で重要なのは システムの可用性や効率性を向上させるだけでなく ビジネスや組織の変化に 容易に対応できるようになること ビジネスと組織の変化に対応する

Slide 24

Slide 24 text

● 単に「規模が大きい」ということではなく、拡張性が高 く、変化に強いということ ● システムが変化に応えるためには、疎結合であることが 求められる ○ テスト容易性、デプロイ独立性 ○ デリバリーまでのリードタイムの短縮・高速化や、デリバリー頻 度の向上 「スケーラブルなアプリケーション」とは

Slide 25

Slide 25 text

クラウドネイティブの複雑さは 現実の複雑さを反映したもの (再掲)

Slide 26

Slide 26 text

● 導入する技術や作成するリソースの目的が曖昧 ○ どんな課題を解決するものなのか? ○ ● システムに対する責任の所在が曖昧 ○ 課題を誰が解決すべきなのか? ○ ● 導入による効果が曖昧 ○ 課題を解決できているのか? ○ クラウドネイティブの複雑さはどこからやってくるのか

Slide 27

Slide 27 text

● 導入する技術や作成するリソースの目的が曖昧 ○ どんな課題を解決するものなのか? ○ 技術選定やリソース作成の目的を明確にする ● システムに対する責任の所在が曖昧 ○ 課題を誰が解決すべきなのか? ○ チームにオーナーシップを持たせて責任の所在を明確にする ● 導入による効果が曖昧 ○ 課題を解決できているのか? ○ 導入による効果を計測し、具体的なアクションに落とし込む クラウドネイティブの複雑さに向き合う

Slide 28

Slide 28 text

● その技術やリソースが解決する課題を明確にする ● 導入の経緯や背景を記録する ● デザインドキュメントを作成する ○ 【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず 書くドキュメント「Design Docs at Google」 ○ 緩やかに死んでいくシステム 技術選定やリソース作成の目的を明確にする

Slide 29

Slide 29 text

● システムの境界とチームの境界を一致させる ○ 必ずしもマイクロサービスアーキテクチャを採用する必要はない ○ モノリスへの回帰も選択肢として検討する https://dev.classmethod.jp/articles/devio2021-microservices/ チームにオーナーシップを持たせる

Slide 30

Slide 30 text

● そのチームが必要なことに集中させる ○ 権限制御によって、他チームのシステムは触れないようにする ■ AWSアカウントやVPC ■ KubernetesクラスターやNamespace ■ Gitリポジトリ、CI/CDパイプライン ○ セキュリティガードレールによる権限の境界により、チームの責 任の境界を明確にする ■ やるべきこと/やらなくていいこと の範囲を明確にする チームにオーナーシップを持たせる

Slide 31

Slide 31 text

● 具体的な評価指標を作成し、計測する ○ デリバリーを高速化したい → 1日あたりのデプロイ回数 ○ 可用性を向上したい → LBの5xx系エラー率 ● チームのパフォーマンスに関する4つの指標 ○ コードのコミットから本番稼働までのリードタイム ○ デプロイ頻度 ○ 障害発生からの平均修復時間 ○ デプロイに伴う変更失敗率 ● 継続的に計測し、改善する Nicole Forsgren Ph.D, Gene Kim, Jez Humble『LeanとDevOpsの科学』(インプレス) 導入による効果を計測する

Slide 32

Slide 32 text

継続的な改善を行う組織文化をつくる

Slide 33

Slide 33 text

● 組織やチームに属するメンバーの行為を規定する、目に 見えない何か ○ 明文化された規則とは異なる、共有された信念や価値観 ○ 明文化されたとしても、実際に体現できているか? ● 個人の行為が組織の文化をつくり、組織の文化が個人の 行為を規定する ○ 個人の行為と組織の文化は、つくり/つくられる関係にある ○ あなたが継続的な改善を行うことで、継続的な改善を行う組織文 化がつくられる 組織文化とは?

Slide 34

Slide 34 text

● 解決すべき課題を明確にし、記録する ○ 他のメンバーにも共有できる形にする ● 簡単なところから、少しずつ、改善を始める ○ はじめから全ての課題を解決しようとしない! ● 効果を計測し、改善の結果を評価する ○ 次の改善活動につなげる 継続的な改善を始めるために

Slide 35

Slide 35 text

Thank you!