Cloud Nativeやる前とやりながら考えておきたいこと

Slide 1

Slide 1 text

Slide 2

Slide 2 text

⾃⼰紹介藤原涼⾺株式会社リクルートテクノロジーズ ITｴﾝｼﾞﾆｱﾘﾝｸﾞ本部ﾌﾟﾛﾀﾞｸﾃｨﾋﾞﾃｨｴﾝｼﾞﾆｱﾘﾝｸﾞ部ｸﾗｳﾄﾞｱｰｷﾃｸﾄｸﾞﾙｰﾌﾟ経歴 2011-2015 ユーザ系SIer にてR&D 2016/1〜リクルートテクノロジーズに⼊社主な活動(社外含む) • コンテナ・クラウド等の先進アーキテクチャの事業への装着 • Rancher JPコアメンバー • 各種勉強会登壇 (Rancher JP meetup, Docker meetup tokyo, Japan Container Days, Cloud Native Daysほか) • 寄稿 @IT 先⾏事例に学ぶKubernetes 企業活⽤の現実・コンテナベースのCI/CD本番事例⼤解剖, ThinkIT マルチクラウド時代の最強コンビ RancherによるKubernetes活⽤ガイド) • 執筆 • RancherによるKubernetes活⽤ガイド(Think IT Books, インプレス) 2 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 3

Slide 3 text

リクルートグループの紹介 3 (C) Recruit Technologies Co.,Ltd. All rights reserved. 創業 1960年3⽉31⽇「⼤学新聞広告社」としてスタートグループ従業員数 45,856名（2019年3⽉31⽇時点）連結売上⾼ 23,107億円（2018年4⽉1⽇〜2019年3⽉31⽇）連結営業利益 2,230億円（2018年4⽉1⽇〜2019年3⽉31⽇）グループ企業数 344社（⼦会社および関連会社、2019年3⽉31⽇時点）⽬指す世界観「あなた」を⽀える存在でありたい

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

本セッションの⽬的 • クラウドネイティブ技術に取り組む前および取り組み中に考える&理解しておいた⽅が良いことを解説 • 取り組んだ中で”あ〜、これって世間にでてるものだけだと⾔葉⾜らずだな”という部分を、解説。 • ⾃分の経験から振り返ってみてどう考えたのかなどをざっくりと共有 7 (C) Recruit Technologies Co.,Ltd. All rights reserved. これから取り組み始める際の参考になれば幸いです

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

取り組む前に考えておきたいこと 1. そもそもクラウドネイティブ技術とはなになのか 2. 技術を活かすにはどう取り組むべきか

Slide 12

Slide 12 text

そもそもクラウドネイティブ技術って? 以下のような要件を満たす技術 • (仮想化技術を中⼼とした) クラウド技術を活⽤して動的な環境を作る • 動的な環境を通じてスケーラブルなアプリケーションを構築、実⾏するための能⼒を組織にもたらす • 回復性・管理性・可観測性を備えた疎結合なシステムを実現する • 上記特性を備えたシステムと堅牢な⾃動化を組み合わせることで、エンジニアがインパクトのある変更を最⼩限の労⼒で頻繁かつ予想通り実施できるようにする。

Slide 13

Slide 13 text

そもそもCloud Nativeって？(もう少しわかりやすく) ⾔い直すと以下の要件を満たす技術 • 様々なレイヤの仮想化を活⽤ • ⾃動で⼤⼩の障害から復旧 • ⾼い管理性を備える • 詳細まで観測できる • 積極的に⾃動化している上記を通じてアプリケーション・インフラの⼤胆な変更を少ない労⼒で実施できる技術 13 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 14

Slide 14 text

そもそもCloud Nativeって？(もう少しわかりやすく) ⾔い直すと以下の要件を満たす技術 • 様々なレイヤの仮想化を活⽤ • ⾃動で⼤⼩の障害から復旧 • ⾼い管理性を備える • 詳細まで観測できる • 積極的に⾃動化している上記を通じてアプリケーション・インフラの⼤胆な変更を少ない労⼒で実施できる技術 14 (C) Recruit Technologies Co.,Ltd. All rights reserved. とはいえこれで⼤丈夫か?そんなに簡単な話なのか？追加で考えないといけないこと、注意点を挙げてみる。

Slide 15

Slide 15 text

Slide 16

Slide 16 text

⾃動で⼤⼩の障害から復旧する Kubernetesをいれれば終わり • そもそもの障害種別の分類と対処⽅法 • 障害といってもいろいろあるけど、それぞれの障害をどうカバーするか • どこまでの障害対策をスコープに含めるか？ • AWSでいうと単⼀のインスタンス・単⼀AZ・単⼀リージョン全体、どこまでをスコープにして復旧または、サービスへの影響が発⽣しないようにするか? • 定めたスコープに対してどうやってSPOFを排除するか? 16 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 17

Slide 17 text

⾃動で⼤⼩の障害から復旧する Kubernetesをいれれば終わり • そもそもの障害種別の分類と対処⽅法 • 障害といってもいろいろあるけど、それぞれの障害をどうカバーするか • どこまでの障害対策をスコープに含めるか？ • AWSでいうと単⼀のインスタンス・単⼀AZ・単⼀リージョン全体、どこまでをスコープにして復旧または、サービスへの影響が発⽣しないようにするか? • 定めたスコープに対してどうやってSPOFを排除するか? 17 (C) Recruit Technologies Co.,Ltd. All rights reserved. どの程度の障害まで配慮するか、それぞれの障害に対してどのような⼿法・テクノロジーで対処するかを考える。 (たしかにk8sはこのレイヤではかなり強⼒なテクノロジーであることは事実)

Slide 18

Slide 18 text

⾃動で⼤⼩の障害から復旧する Kubernetesをいれれば終わり • そもそもの障害種別の分類と対処⽅法 • 障害といってもいろいろあるけど、それぞれの障害をどうカバーするか • どこまでの障害対策をスコープに含めるか？ • AWSでいうと単⼀のインスタンス・単⼀AZ・単⼀リージョン全体、どこまでをスコープにして復旧または、サービスへの影響が発⽣しないようにするか? • 定めたスコープに対してどうやってSPOFを排除するか? 18 (C) Recruit Technologies Co.,Ltd. All rights reserved. そこまで考えた上でKubernetesなり、ECSなりのテクノロジーの備える諸機能で対応するといった話になる

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

⾼い管理性を備える管理性が⾼いとはそもそもどういうことか? • ⼿間がかからない(間違ってはないが…) • コードによる管理が可能 22 (C) Recruit Technologies Co.,Ltd. All rights reserved. コードによる管理が可能 = ソフトウェア⼯学的な改善アプローチが適⽤しやすくなる⼯学的な改善アプローチがポイント種々の活動の再現性向上(≒属⼈性の低減)を実現するための⼿段を考えられるようになる

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

詳細まで観測することができる道具は揃っている(OSSから商⽤まで幅広く) • 詳細まで観測してどうする? 27 (C) Recruit Technologies Co.,Ltd. All rights reserved. 観測結果(特に平常時と異なる状態が⾒られた場合)に応じたアクションにつながるものでなければ価値は低い。クラウドネイティブ技術はアクションを⾃動化することを容易にはする。どんなアクションをとるかについては⼈間が考えなければいけない

Slide 28

Slide 28 text

Slide 29

Slide 29 text

⾃動化が積極的に⾏われている⾃動化するだけでは運⽤が最終的に破綻する • メンテナンス可能な⾃動化形態にできるか • 可能な限り環境が異なる場合も同じコード・設定で利⽤できるか • 環境による可変部分を最⼩化できるか 29 (C) Recruit Technologies Co.,Ltd. All rights reserved. ただし、相⼿はコードなのでまだ打つ⼿はあるソースコードのリファクタリングといった話になる (あまりコード書いたりが得意でないインフラエンジニアにはおそらく最も⾟いところ)

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

考えなければいけないことはたくさんあるが… • 実はクラウドネイティブ関係なく本来は考えなきゃいけないこと • IPAの⾮機能要求グレードなどを広く捉えた場合 (https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html) 32 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 33

Slide 33 text

考えなければいけないことはたくさんあるが… • 実はクラウドネイティブ関係なく本来は考えなきゃいけないこと • IPAの⾮機能要求グレードなどを広く捉えた場合 (https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html) 33 (C) Recruit Technologies Co.,Ltd. All rights reserved. クラウドネイティブ技術は⾮機能に関連した課題について部分的ではあるものの標準的かつ(以前に⽐べて)実現が容易な解決案をあたえてくれるだけそれを活かすプロセスについてはノータッチ(あくまでも技術なので)

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

クラウドネイティブ技術と DevOps クラウドネイティブ技術 + DevOps⽂化・プロセス • クラウドネイティブ技術 • ⾼い⾮機能品質を実現するため技術を提供 • ⾼頻度なデプロイを⽀援するための仕組みを提供(特に重要なポイントなので抽出) • DevOps⽂化・プロセス • ⾼速な仮説検証サイクルを回すための組織⽂化・プロセスを醸成 • ビジネスに直接貢献する部分はこちら 38 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 39

Slide 39 text

クラウドネイティブ技術と DevOps クラウドネイティブ技術 + DevOps⽂化・プロセス • クラウドネイティブ技術 • ⾼い⾮機能品質を実現するため技術を提供 • ⾼頻度なデプロイを⽀援するための仕組みを提供(特に重要なポイントなので抽出) • DevOps⽂化・プロセス • ⾼速な仮説検証サイクルを回すための組織⽂化・プロセスを醸成 • ビジネスに直接貢献する部分はこちら 39 (C) Recruit Technologies Co.,Ltd. All rights reserved. ⽂化やプロセスがあって初めてクラウドネイティブ技術が活きる。⽂化やプロセスを技術でブースト(≒実現を容易化・効果を最⼤化)する

Slide 40

Slide 40 text

Slide 41

Slide 41 text

DepOps ＋クラウドネイティブ技術において特に重要な技術的ポイント • コードリポジトリ(⼤前提) • 様々なレイヤのコード化を通じた再現性の向上 • テストの⾃動化 + テスト駆動開発(+ テスト環境の動的な払い出し) • テスト駆動開発と開発スピードについては下記URLを参照 • 質とスピード(https://speakerdeck.com/twada/quality-and-speed, t-wada) • デプロイプロセスのシンプル化・⾃動化 41 (C) Recruit Technologies Co.,Ltd. All rights reserved. エンジニア個々⼈が品質に対する責任を果たしやすくするここまでやったからには失敗したら誰のせいとかではないよねと⾔える状態の実現を⽬指す。

Slide 42

Slide 42 text

DepOps ＋クラウドネイティブ技術において特に重要な技術的ポイント • コードリポジトリ(⼤前提) • 様々なレイヤのコード化を通じた再現性の向上 • テストの⾃動化 + テスト駆動開発(+ テスト環境の動的な払い出し) • テスト駆動開発と開発スピードについては下記URLを参照 • 質とスピード(https://speakerdeck.com/twada/quality-and-speed, t-wada) • デプロイプロセスのシンプル化・⾃動化 42 (C) Recruit Technologies Co.,Ltd. All rights reserved. エンジニア個々⼈が品質に対する責任を果たしやすくするここまでやったからには失敗したら誰のせいとかではないよねと⾔える状態の実現を⽬指す。⾮難のないポストモーテムとそこからの確実な学びへと繋げる

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Cloud Native Trail Map 51 (C) Recruit Technologies Co.,Ltd. All rights reserved. https://github.com/cncf/trailmap 1. コンテナ化 2. CI/CD 3. オーケストレーション・アプリケーション定義 4. 可観測性と分析 5. サービスプロキシ・ディスカバリ・メッシュいったん5までで解説 (6以降は完全に未経験なので)

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Cloud Native Trail Map (何を達成することを期待するかの⼀例) 1. コンテナ化 – ビルドの定型化 2. CI/CD – テストプロセスの定型化 – デプロイプロセスの定型化 3. オーケストレーション・アプリケーション定義 – デプロイ後の定性的な⾮機能品質の実現 – ある程度複雑なアプリケーションのデプロイプロセスの単純化・定型化 4. 可観測性と分析 – デプロイ後の定量的な⾮機能品質の測定 – 観測結果を⽤いた改善の判断 5. サービスプロキシ・ディスカバリ・メッシュ – より複雑なデプロイプロセスの実現(カナリアリリースなど) 53 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 54

Slide 54 text

Cloud Native Trail Map (何を期待するのかの⼀例) 1. コンテナ化 – ビルドの定型化 2. CI/CD – テストプロセスの定型化 – デプロイプロセスの定型化 3. オーケストレーション・アプリケーション定義 – デプロイ後の定性的な⾮機能品質の実現 – ある程度複雑なアプリケーションのデプロイプロセスの単純化・定型化 4. 可観測性と分析 – デプロイ後の定量的な⾮機能品質の測定 – 観測結果を⽤いた改善の判断 5. サービスプロキシ・ディスカバリ・メッシュ – より複雑なデプロイプロセスの実現(カナリアリリースなど) 54 (C) Recruit Technologies Co.,Ltd. All rights reserved. ツール選定・個別の機能をどこで実現するかについてはを期待する内容を軸にして考えると納得感のある構成となりやすい (参考) Kubernetes、コンテナ技術を活⽤した開発アジリティー向上にインフラアーキテクトはどう貢献したのか (@IT, https://www.atmarkit.co.jp/ait/articles/1902/18/news013.html)