ITmedia DX Summit Vol.7 -Day 4- / 2021/3/11 SUDA Kazuki, Cloud Native Ambassador / Co-organizer of Kubernetes Meetup Tokyo @superbrothers まず何から始めるべきか Web 系も従来企業も関係ない「実践の鉄則」とは？ クラウドネイティブへの判断基準と 正しいロードマップの描き⽅

@superbrothers SUDA Kazuki / @superbrothers ▶ ソフトウェアエンジニア ▶ Kubernetes Meetup Tokyo, Prometheus Meetup Tokyo ほか、共同主催者 ▶ Cloud Native Ambassador (CNCF) ▶ 「Kubernetes実践⼊⾨」、「みんなのDocker/Kubernetes」共著書（技術評論社） ▶ 「⼊⾨ Prometheus」、「Kubernetes で実践するクラウドネイティブ DevOps」監訳書 （オライリー・ジャパン） 2

@superbrothers アジェンダ ▶ Kubernetes を取り巻く現状を理解する ▶ 「クラウドネイティブ」流⾏りにただ乗るだけじゃない、⽬的を再確認する ▶ ⽬的を達成するためにベターな技術を選択する ▶ クラウドネイティブに向けて、どこから取り組むべきか 3

@superbrothers Kubernetes を取り巻く現状を理解する

@superbrothers Kubernetes（クバネテス） ▶ コンテナオーケストレーションツール + 複数のマシン（ノード）で構成されるクラスタに対してコンテナの配備、設定、管理を⾏う ▶ κυβερνήτης: ギリシャ語で操舵⼠ ▶ Google の社内システムからインスパイアされたオープンソースソフトウェア ▶ 2015年7⽉に 1.0.0 をリリース、2021年3⽉時点の最新バージョンは 1.20 5 “Kubernetes is open source—a contrast to Borg and Omega,
 which were developed as purely Google-internal systems. “ Borg, Omega, and Kubernetes

ホスト コンテナ コンテナ コンテナ コンテナ コンテナ コンテナ ホスト コンテナ コンテナ コンテナ コンテナ コンテナ コンテナ ロードバランサ 永続ストレージ Kubernetes デプロイ戦略 ネットワーク ホスト コンテナ コンテナ コンテナ コンテナ コンテナ コンテナ コ コ コ

@superbrothers Kubernetes（クバネテス） ▶ 初期は Google のソフトウェアだったが、その後 Cloud Native Computing Foundation（CNCF）に譲渡され、 現在は CNCF がホストするオープンソースプロジェクト ▶ 「10年以上に渡りコンテナを本番環境で運⽤してきた Google の経験と 多くの企業によるコミュニティの優れたアイデアと⼿法が組み込まれている」 7

No content

ベアメタル Kubernetes はどこでも使える

@superbrothers Kubernetes を取り巻く業界の状況 ▶ 「Kubernetes is boring （Kubernetes は退屈）」 + v1.0.0 のリリースから6年、主な機能はすでに安定 + エコシステムとユーザコミュニティは引き続きの拡⼤ ▶ 採⽤企業が拡⼤の⼀途 + 市場では既に『Kubernetesはキャズムを越えた』と評価する声がある *1 + ヤフー株式会社: 「ヤフーは2017年の夏にKubernetesを本番運⽤で使い始めて、... 今では、680以上のクラスタを運⽤しています。」 *2 + みんなの銀⾏: 「MAINRIは、「Kubernates」（Google Kubernetes Engine）を利⽤した クラウドネイティブなアプリケーション基盤を採⽤する。」 *3 ▶ コンサルティングや教育サービスも拡充 + 企業をサポートする IT 企業も拡⼤ 10 *1 https://www.atmarkit.co.jp/ait/articles/2008/13/news097.html *2 https://logmi.jp/tech/articles/323803 *3 https://www.itmedia.co.jp/enterprise/articles/1912/11/news125.html

@superbrothers Kubernetes は今や先進企業だけのものではない。

@superbrothers 「クラウドネイティブ」 流⾏りにただ乗るだけじゃない、 ⽬的を再確認する

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

@superbrothers クラウドネイティブなアプリケーション 14 ⾃動化可能 アプリケーションを⼈間の代わりにマシン、ソフトウェアによってデプロイおよび管理する ポータブル ディスクなどの物理リソースやマシンに関する詳細な知識から切り離すことで、 マシンやクラスタ間、さらにはクラウド間で容易に移動できる 分散化 コードを単⼀のエンティティ（モノリスと呼ばれます）としてデプロイする代わりに、協調し て動作する複数の分散化されたマイクロサービスから構成される傾向がある スケーラブル 分散化されたアプリケーションは、冗⻑性や優雅な劣化（グレースフル・デグラデーション） を通じて⾼度な可⽤性を実現する ダイナミック コピーを数多く実⾏して⾼可⽤性を実現することや、ローリングアップデートを実施して、 トラフィックを取りこぼすことなくサービスを円滑にアップグレードできる 観測可能 分散システムの性質上、プロファイリングやデバッグが難しくなるため、オブザーバビリティ （可観測性）が重要な要件になる 「Kubernetesで実践するクラウドネイティブ DevOps」（オライリー・ジャパン）からの引⽤

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

@superbrothers エンジニアだけじゃない、ビジネスの成⻑に不可⽋になっている ▶ アイデアをいかに早く本番に届けられるかが競合に勝つための⼤きな要因になっている + スピード（速さ）とアジリティ（俊敏性） ▶ ⼀⽅で、ユーザは信頼性の⾼いサービス提供を要求している + ユーザは信頼性が低いことをもはや受け⼊れず、競合相⼿に簡単に移動する インパクトのある変更を最⼩限の労⼒で頻繁かつ予測どおりに⾏う必要がある 16

@superbrothers 「クラウドネイティブ」というベストプラクティス クラウドネイティブは、「インパクトのある変更を最⼩限の労⼒で頻繁かつ予測どおりに⾏う」ための ベストプラクティス ▶ 静的ではなく動的（ダイナミック）な環境 + マシンや VM、ストレージなどの IT インフラを要求に応じてオンデマンドに作成 + プログラマブルで⾃律的 ▶ スケーラブルなアプリケーションを構築および実⾏する + 道具や⼿法として、コンテナ、サービスメッシュ、マイクロサービス、イミュータブル インフラストラクチャ、および宣⾔型 API などがある ▶ 堅牢な⾃動化への取り組み + 継続的インテグレーション（CI）、予測可能な継続的デプロイメント（CD） ▶ システムは、回復性、管理⼒、および可観測性を持たせ疎結合にする + 障害時に機能を維持でき、管理がしやすく、外部から観測できる 17

@superbrothers ⽬的を達成するために技術的な⼿法に留まらないことも必要 「インパクトのある変更を最⼩限の労⼒で頻繁かつ予測どおりに⾏う」を達成するためには、 開発運⽤の⼿法や組織にまで変更が求められる ▶ アジャイル開発 ▶ DevOps ▶ コンウェイの法則 / 逆コンウェイの法則 18

@superbrothers クラウドネイティブは、「Kubernetes を使う」ことではない Kubernetes は強⼒な機能を持っているが、すべての企業や組織で最適であるとは限らない。 すべてはケースバイケースで、銀の弾丸などない。 また、Kubernetes を使わずともクラウドネイティブに取り組める。 ▶ 多分あなたにKubernetesは必要ない | Yakst*1 + 「Kubernetesはコンテナオーケストレーションの巨⼈です。 ... 特に⼩さなチームにおいて、メン テナンスに時間をとられますし習得までの道のりは険しいものです。私たち4⼈のチームがtrivago で達成したかったことにおいて、Kubernetesはオーバヘッドがありすぎました。」 19 *1 https://yakst.com/ja/posts/5455

@superbrothers ⼿段を⽬的にしない。 Kubernetes を使うことがクラウドネイティブではない。

@superbrothers ⽬的を達成するために ベターな技術を選択する

@superbrothers X as a Service 22 物理インフラ OS サーバ仮想化 ミドルウェア ランタイム アプリケーション 物理インフラ OS サーバ仮想化 ミドルウェア ランタイム アプリケーション 物理インフラ OS サーバ仮想化 ミドルウェア ランタイム アプリケーション IaaS CaaS PaaS コンテナ化 ファンクション ファンクション ファンクション 物理インフラ OS サーバ仮想化 ミドルウェア ランタイム アプリケーション ファンクション FaaS 責任分界点、クラウド事業者が管理 ⽣産性が⾼い ⾃由度が⾼い

@superbrothers どれがベターなのかはケースバイケース ワンウェイドアにしない、ツーウェイドアにする。 ▶ 試しでやってみる、ダメだったらやめればいい + やってみないとわからないことは多い。想像で決めない。早く失敗する。 + 失敗したからといって無駄なわけではなく、うまくいかなかった⽅法を知れる ▶ パブリッククラウドなのか、オンプレなのか + パブリッククラウドの場合は、実⾏基盤を⽐較的容易に変更できるため⽣産性に振る （FaaS、PaaS、CaaS ） + オンプレの場合は、実⾏基盤を容易に変更できないためできる限り広いユースケースに 対応できる基盤が望ましい（CaaS、IaaS） + 抽象度の⾼い基盤はより抽象度が低い基盤に上にしか構築できない + CaaS の上に PaaS は構築できるが、PaaS の上に CaaS は構築できない 23

@superbrothers もっと簡単で退屈な⽅法によって⽬的を達成できないかを考える ⽬的が達成できるなら Kubernetes でなくていい。 ▶ それを考えるにはその技術は何が得意で何が得意ではないのか、 何ができて何ができないのかが分からなければいけない + 技術の特性を理解し、合わせて現場の現実に則して考えられる⼈材が必要 + 学習コストが⾼いかどうかやそもそも習得可能かどうかも組織次第 ▶ 例えば Kubernetes 単体ではステートフルアプリケーションの管理はまだまだ難しい + ⽬的を達成するために難しいことに取り組む必要があるのかどうか + 難しいことに取り組むと会社が儲かるのかどうか 24

@superbrothers どのように新しい技術を学習し、キャッチアップするか ▶ 技術コミュニティに参加する + 競争はビジネスで⾏い、技術的な課題は企業の垣根を超えて解決に取り組む + 情報を受け取るだけではなく発信する側に回る ▶ コミュニティのなかに⼊っていける、 情報を発信してコミュニティで課題に⽴ち向かっていくという意識を持っている⼈材がとくに重要 + 企業は、社員のコミュニティへの参加や情報発信をサポートする必要がある つまり「テクノロジ企業」にならなければならない。 ▶ ⾃分たちで判断しなければならない / 内製化 ▶ そもそも⾃社のシステムがどう構成されているか、どのようなアプリケーションがどう実⾏され 管理されているのかを把握している⼈がいるか 25

@superbrothers 26 どの技術がベターなのかは「場合による」。 やらないとわからないのでまずやってみる。 そもそも⾃分たちのシステムやアプリケーションが どう構成されているのかを知らないと始めらない。

@superbrothers クラウドネイティブに向けて、 どこから取り組むべきか

@superbrothers クラウドネイティブトレイルマップ https://github.com/cncf/tailmap

@superbrothers クラウドネイティブを実践する 1. CI / CD（継続的インテグレーションと継続的デリバリ） 2. スケーラブルなアプリケーションの開発 3. コンテナ化 4. オーケストレーションとアプリケーション定義 5. オブザーバビリティと監視 29

@superbrothers 1. CI /CD （継続的インテグレーションと継続的デリバリ） 30 開発者 コミット バージョン管理 システム CI / CD ツール テスト ビルド 配信 アーティファクト レジストリ テスト環境 ステージング環境 デプロイ ソフトウェアリリースプロセスの⾃動化

@superbrothers 2. スケーラブルなアプリケーションの開発 The Twelve Factor App を実践する。 1. バージョン管理されている1つのコードベースと複数のデプロイ 2. 依存関係を明⽰的に宣⾔し分離する 3. 設定を環境変数に格納する 4. バックエンドサービスをアタッチされたリソースとして扱う 5. ビルド、リリース、実⾏の3つのステージを厳密に分離する 6. アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏する 7. ポートバインディングを通してサービスを公開する 8. プロセスモデルによってスケールアウトする 9. ⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する 10.開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ 11.ログをイベントストリームとして扱う 12.管理タスクを1回限りのプロセスとして実⾏する 31 https://12factor.net/

@superbrothers 3. コンテナ化 ▶ アプリケーションをコンテナとして実⾏する ▶ ステートレスアプリケーションはコンテナでの利⽤が容易になっている ▶ PaaS / FaaS が選択できればコンテナ化が必要なくなる（ソースコードから直接デプロイ） 32 4. コンテナオーケストレーションの導⼊ ▶ コンテナの配備、設定、管理の⾃動を⾃動化する ▶ Kubernetes は、コンテナオーケストレーションツールのデファクトスタンダード ▶ Kubernetes を利⽤する場合は、どうしてもできない場合を除いてマネージドサービスを選択する ▶ PaaS / FaaS が選択できれば、インフラを意識することなく、 アプリケーション / ファンクションの配備、設定、管理を⾃動化できる

@superbrothers 5. 監視とオブザーバビリティ（可観測性） 監視が「システムが正しく機能しているかどうか」を⽰すのに対して、 オブザーバビリティが確保された監視は「システムがどうして正しく機能しないのか」を⽰す。 ▶ システムのオブザーバビリティといえば、「測定のしやすさがどれほど担保されているか」 および「内部で何が起こっているかをどれほど容易に判断できるか」を⽰す尺 ▶ オブザーバビリティは、システムの理解を促進する + システムの改善が意図したとおりに機能するかどうかの判断材料を提⽰できる + 「推測するな計測しろ」 33

@superbrothers メトリクスによる監視 ▶ 何かの状態を測定した数値で、集計した結果から経時的にどのように変化しているかを明らかにする + アプリケーション: HTTP リクエスト数やリクエストの処理にかかった時間 + インフラ: プロセスやコンテナの CPU 使⽤率、ディスク I/O、ネットワークトラフィック ▶ できる限りのコンテキストを無視することで、データ量と処理を合理的な範囲に維持する 34

@superbrothers 段階的にゴールを設定する ▶ ⼤きな⽬標をたくさんの⼩さなステップに分割する ▶ 新しいことに取り組む場合は間違った選択する可能性が⾼いので、致命的な問題があった場合にも ⼿戻りを最⼩化できるように考える 35 まずデプロイする ▶ リリースではない。ユーザに提供しない形で本番にデプロイする。 ▶ デプロイを繰り返していくなかで新しいデプロイプロセスに慣れていく。 ▶ ある程度⼿動でやってみて、プロセスが固まってきたらそれを⾃動化すればよい

@superbrothers 複数の⽬的に⼀緒に達成しようとしない ▶ 「コンテナ化、Kubernetes 上での実⾏に合わせて、アプリケーションをフルスクラッチで書き直し てマイクロサービス化しよう」 + 本当によくある間違い、ぜったいダメ ▶ ⼤きな⽬標をたくさんの⼩さなステップに分割する 36 監視の⼿法が変わることを意識しておく ▶ ダイナミックな環境においては、これまでの静的な監視ではなくダイナミックな監視が必要になる + サービスディスカバリ（サービスの発⾒）

@superbrothers 37 CI / CD、ステートレスなアプリケーションの開発は クラウドネイティブ関係なく必要。 段階的にゴールを設定して、まずデプロイする、 まずやってみる。

@superbrothers まとめ

@superbrothers まとめ ▶ Kubernetes、クラウドネイティブを取り巻く企業の現状を理解する + Kubernetes は今や先進企業だけのものではない。 ▶ 「クラウドネイティブ」流⾏りにただ乗るだけじゃない、⽬的を再確認する + クラウドネイティブは、「インパクトのある変更を最⼩限の労⼒で頻繁かつ予測どおりに⾏う」 ためのベストプラクティス + Kubernetes を使うこと、⼿段を⽬的にしない。クラウドネイティブに取り組むのに 優れた多くの選択肢にある。 ▶ ⽬的を達成するためにベターな技術を選択する + どの技術がベターなのかは「場合による」。やらないとわからないのでまずやってみる。 + ⾃分たちのシステムやアプリケーションがどう構成されているのかを知らないと始めらない。 ▶ クラウドネイティブに向けて、どこから取り組むべきか + とくに重要なのは「CI / CD」と「ステートレスなアプリケーションの開発」 + 段階的にゴールを設定して、まずデプロイする、まずやってみる 39