Platform Engineeringでクラウドの「楽しくない」を解消しよう

by Kazuto Kusama

Slide 1

Slide 1 text

Platform Engineeringでクラウドの「楽しくない」を解消しよう @jacopen

Slide 2

Slide 2 text

今日はプラットフォームエンジニアリングの話をしにきました！ ※ 資料公開にあたって、登壇時に口頭で補足していた部分はこの右下枠で解説します

Slide 3

Slide 3 text

Platform Engineeringとは開発者体験と生産性を向上させるためにセルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野 Platform Engineeringの定義を調べると、いろいろ出てきます。たとえばこんなやつとか。でも、みなさんはコレ覚える必要ないです

Slide 4

Slide 4 text

でも、みなさんはプラットフォームのことなんて忘れちゃって良いです！

Slide 5

Slide 5 text

AWS、楽しんで使ってますか？今日、一番話したいこと

Slide 6

Slide 6 text

楽しい！ JAWS DAYSという、休日にも関わらず喜んで参加する人ばかりのイベントだったんで、多くの人が手を上げられていました

Slide 7

Slide 7 text

個人で気軽に使うにはいいけど仕事として使うときは楽しくないこともある･･･ただ、こういうイベントにはきてないけど、辛いなーと思いながらAWS使ってる人もいるでしょう

Slide 8

Slide 8 text

どういうときに『楽しくない』のか ● やりたいことができないとき ● 意図した通りに動いてくれないとき ● 忙しすぎて手が回らないとき ● 集中したいことに集中できないとき ● 翻訳されたドキュメントがよく分からないとき ● でも英語読んでもよく分からないとき

Slide 9

Slide 9 text

Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association Organizer @CloudNative Days

Slide 10

Slide 10 text

About me ● PagerDutyという、インシデントを管理する SaaSのプロダクトエバンジェリスト ● 前職はHashiCorpでTerraformやVaultのプリセールスエンジニア ● その前はPivotal/VMwareでPaaSプロダクトのプロフェッショナルサービス ● さらにその前は通信事業者でクラウドサービスを作るエンジニアなので、基本的にはプラットフォーム側の人間です

Slide 11

Slide 11 text

でもたまにアプリを書くことも CloudNative Days 独自イベントプラットフォーム Dreamkast 汗中成分分析サービスによるインナーケアアシスト PITTAN

Slide 12

Slide 12 text

アプリを作っていて思うことこの開発したアプリをAWSにデプロイしないといけないけど･･･クラウドくっそめんどくさい！こんな作業やりたくない！ ▲ 一応クラウド系のエンジニア

Slide 13

Slide 13 text

● クラウドやコンテナの知識は持ち合わせている ● でも、アプリを書いているときは、頭の中は開発モード ● 開発モードからクラウドエンジニアモードに頭を切り替えるのはくっそめんどくさい ● クラウドエンジニアモードから開発モードに戻すのもくっそめんどくさいアプリを作っているときは元HashiCorpですし、Terraformの本も出したりしてるんですが、そんな自分からしても開発してる途中に HCLなんて書きたくないです。じゃあCDKでTypeScriptだと解決？いや、そういう話ではないです。それも頭切り替え必要なの変わんないです

Slide 14

Slide 14 text

くっそめんどくさい！

Slide 15

Slide 15 text

くっそめんどくさい！

Slide 16

Slide 16 text

僕が思う、AWSが楽しくないとき ● 学習の負荷が高すぎるとき ○ 適度な学習の負荷なら、好奇心が勝って『楽しい』 ○ 自分のキャパ超えてくると『楽しくない』 ■ 単純に必要スキルが自分のレベルを超えている ■ 情報が散在している結果、『検索する』という本質的ではない作業に追われる ■ 気に障るブロッカー ● コンテキストスイッチが多すぎるとき ○ TypeScript⇨HCL⇨TypeScript⇨YAMLみたいな反復横跳びしんどい ● 今、注力したいのは『そっちじゃない』とき ○ アプリの開発に注力したいのに･･･! ○ UX考えるのに時間を使いたいのに！

Slide 17

Slide 17 text

● デプロイするためのDockerﬁle書き、imageづくり ● Manifest書き ● CI/CDパイプライン作成 ● 認証基盤との連携 ○ OIDCのフローとか何回勉強しても忘れちゃうんだけど･･･ ● ロギング、モニタリングの設定 ● セキュリティスキャン ● IaCのコード書き ● etc… アプリをデプロイしたいだけなのにやるべきことが多い！みなさんも、くっそめんどくさい経験ありませんか？

Slide 18

Slide 18 text

くっそめんどくさい！の表現を専門用語にすると認知負荷

Slide 19

Slide 19 text

https://www.infoq.com/articles/platform-engineering-primer/ より引用認知負荷の増大が問題にクラウドの浸透、クラウドネイティブ技術の登場、マイクロサービス化の流れ、エンジニアの責任範囲の拡大により認知負荷が大変なことに

Slide 20

Slide 20 text

くっそめんどくさい！は気のせいではなくあちこちで発生している差し迫った課題

Slide 21

Slide 21 text

認知負荷の増大による生産性の低下が無視出来なくなりつつある

Slide 22

Slide 22 text

じゃあ、どうすればいいのか

Slide 23

Slide 23 text

分業しよう！

Slide 24

Slide 24 text

人類の発明『分業』 ● 世界で初めて分業について解説したのは、 18世紀の経済学者アダム・スミス ● ピン工場の例を用いて分業の効率性を説いた ○ 1人の職人が分業無しでピンを作ろうとすると、1日に20本程度 ○ 工場では、18の工程に分けられ、10人の作業者が分担 ■ 針金を引き延ばす ■ 針金を真っ直ぐにする ■ 切断する ■ 先端を尖らせる ■ (以下略) ○ こうすることで、1日に48,000本生産できる ■ 生産性240倍向上！

Slide 25

Slide 25 text

なぜ分業で効率が向上するのか ● 各作業者が特定の作業に特化することで熟練度が向上する ● 異なる作業間の移動時間が節約される ● 各作業に特化した工具や機械の開発が促進される

Slide 26

Slide 26 text

よっしゃ、じゃあ分業だ！ Build Test Ship Run 開発運用そういえばIT業界は数十年前から分業してましたね。こんな感じで

Slide 27

Slide 27 text

よっしゃ、じゃあ分業だ！ Build Test Ship Run 開発運用 💢 💢 でも、この分業スタイルは上手くいかないってのは歴史が証明しているわけです

Slide 28

Slide 28 text

あれでしょ、DevOpsってやつでしょ Build Test Ship Run 開発運用じゃあDevOps？思われる方もいるでしょう。この考え方は悪くないしこれからも重要ではあるんですが

Slide 29

Slide 29 text

システム障害はどういうときに起きるか “障害のほとんどはデプロイによって引き起こされる。したがって、デプロイが増えると障害も増え、結果としてインシデント管理、軽減策、ポストモーテムが必要となる” エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのかより引用

Slide 30

Slide 30 text

あれでしょ、DevOpsってやつでしょ Build Test Ship Run 開発運用信頼性を第１にしたい生産性を第１にしたいそれぞれ大事にしたいポイントが違うんで、上手くいかないこともあるんですね。信頼性上げるための改善を開発にしてほしいけど、優先順位が上がらない･･･とか。

Slide 31

Slide 31 text

You build it, you run it. Werner Vogels, VP & CTO of Amazon 我らがAmazonのVP&CTO が、かつてこういうことを言いました

Slide 32

Slide 32 text

フルサービスオーナーシップ「コードを書いた者が、その責任を負う」 ● 設計と実装の点から見て、テクノロジーに最も精通した人が製品開発ライフサイクル全体の責任を引き受ける運用モデル ● 本番環境において自分が書いたコードの責任を負うよう、最もシンプルな形でエンジニアに権限を与える ● 呼び方は色々ある ○ フルサイクル・デベロッパー (Netflix) https://netflixtechblog.com/full-cycle-developers-at-netflix-a08 c31f83249

Slide 33

Slide 33 text

“コードに責任を持つ” メリット ● サービス品質が上がる ○ 開発と運用を分けず一貫して担当することで、リリース後の振る舞いまで考慮してコードを書くようになる。だれも深夜に叩き起こされたくないので。 ● 障害対応の迅速化 ○ 開発者がオンコールにいれば対応のスピードが格段に上がる。自分たちが開発したシステムを熟知しているため、原因特定や復旧が素早く行える。

Slide 34

Slide 34 text

“コードに責任を持つ” メリット ● フィードバックループの高速化 ○ 開発者が日常的に運用に関与すると、ユーザーからの生のフィードバックや本番環境での問題点が直接開発チームに届く ○ 「不具合→修正」のサイクルが短くなり、サービスの継続的な改善がスピーディーに行える ● 運用負荷の軽減とチーム連携の強化 ○ 従来運用担当に集中しがちだった負荷が分散される。特定の運用チームだけに深夜対応などの負担がかかる状況を和らげ、組織全体で信頼性向上に取り組む姿勢が生まれる

Slide 35

Slide 35 text

つまりこう Build Test Ship Run 開発

Slide 36

Slide 36 text

あれ、分業どこいった

Slide 37

Slide 37 text

DevとOpsという分業スタイルが、時代に合わない ● そもそもDevとOpsという分け方自体が、このクラウド時代・AI時代に合ってない ● クラウドやクラウドネイティブで高度化・高速化・自動化できたら、開発担当と運用担当で分業することのデメリットが目立つようになる

Slide 38

Slide 38 text

これからの分業スタイル

Slide 39

Slide 39 text

Team Topologies 価値のあるソフトウェアを素早く届けられるようにするための組織設計。 4タイプのチーム定義と、3つのインタラクションモードが定義されている。

Slide 40

Slide 40 text

4つのチームタイプ Stream-aligned team ビジネスのストリームに沿って配置するチーム。ビジネスの中心 Complicated Subsystem team 複雑なサブシステムやコンポーネントを扱うチーム。その分野のスペシャリストが集まる Enabling team 他のチームが新しい技術やスキルを身につける支援をするチーム ★Platform team インフラやツール、共通サービスなどのプラットフォームを提供するチーム

Slide 41

Slide 41 text

3つのインタラクションモードファシリテーション一方のチームが他のチームの障害を取り除くために支援をしたり、支援されたりする。同時に複数のチームと連携することもあるコラボレーション 2つのチームが密接に協力して作業する。同時にコラボレーションできるのは1チームまで ★X-as-a-Service 他のチームが提供するものをサービスとして利用する関係性。責任分界点が明確。疎結合。

Slide 42

Slide 42 text

Team Topologiesでは、DevとOpsに分けない Stream-aligned team 開発から運用まで、ビジネス価値に関するところを一気通貫で担う You build it, you run itの原則を体現するここで重要なのは、Stream-aligned Teamは DevとOpsみたいに分けてないこと。Stream に関して1チームが責任を負うスタイル。

Slide 43

Slide 43 text

例の、くっそめんどくさい対策 ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。適切な情報提供をお願いしたい

Slide 44

Slide 44 text

例の、くっそめんどくさい対策 ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。適切な情報提供をお願いしたいその道のプロ = Platform Team その道のプロを体系だって作っていく取り組み = Platform Engineering 正直Platform Engineeringの理解は、この程度でいいと思います

Slide 45

Slide 45 text

Platform Engineeringとは開発者体験と生産性を向上させるためにセルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野冒頭にも紹介したように、定義みたいなものはあります。

Slide 46

Slide 46 text

Platform Engineeringでよく出る2つのIDP 開発チームがインフラやツールを効率的に利用できるようにするための内部向けプラットフォームインフラ、CI/CD、監視、認証などを抽象化し、開発チームがアプリ開発に集中できるようにする。インフラやサービスの自己管理を支援し、「セルフサービス」で素早く安全に操作できるように設計する。 Internal Developer Platform Internal Developer Portal 開発者向けのインターフェース。 Internal Developer Portalに含まれることも多い自社のサービスやインフラ、ツールの情報を一元化し、開発者が必要なリソースや情報に簡単にアクセスできるようにしたもの。ドキュメントやAPI仕様、サービスの稼働状況をカタログ形式で表示したり、検索可能にしたりする。 Platform Engineeringについて調べると、こういう2 つのIDPに関する情報が出てきます

Slide 47

Slide 47 text

Platform Engineeringでよく出る2つのIDP 開発チームがインフラやツールを効率的に利用できるようにするための内部向けプラットフォームインフラ、CI/CD、監視、認証などを抽象化し、開発チームがアプリ開発に集中できるようにする。インフラやサービスの自己管理を支援し、「セルフサービス」で素早く安全に操作できるように設計する。 Internal Developer Platform Internal Developer Portal 開発者向けのインターフェース。 Internal Developer Portalに含まれることも多い自社のサービスやインフラ、ツールの情報を一元化し、開発者が必要なリソースや情報に簡単にアクセスできるようにしたもの。ドキュメントやAPI仕様、サービスの稼働状況をカタログ形式で表示したり、検索可能にしたりする。気にしなくていいでも、こんなの気にしなくて良いです。

Slide 48

Slide 48 text

あーあれでしょ共通基盤作ろうってやつでしょ大きな会社なら必要あるかもだけどウチはまだそういう感じじゃないかなーだってIDPの話しちゃうと、こう思っちゃう人も多いでしょう？

Slide 49

Slide 49 text

Platform Engineeringとは開発者体験と生産性を向上させるためにセルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野この定義も気にしなくていいこの定義だって気にしなくて良いです。忘れちゃってください

Slide 50

Slide 50 text

Platform Engineeringを成功させるコツはプラットフォームのことなんて忘れること

Slide 51

Slide 51 text

めちゃくちゃシンプルにいうと『くっそめんどくさい』『楽しくない』 Platform Engineering 『楽しい！』 Platform Team

Slide 52

Slide 52 text

本質は開発者体験開発生産性を高める取り組み

Slide 53

Slide 53 text

Team Topologiesから考える、チームの関わり方開発チームその道のプロ開発チームその道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を開いたり、Slackで情報提供その道のプロが開発チームにジョインし Manifest書くのを担う開発チームその道のプロ XaaS その道のプロが用意したプラットフォームのレールの上で開発

Slide 54

Slide 54 text

Slide 55

Slide 55 text

1:多で、Stream-aligned Teamを支援する開発チームその道のプロ Facilitating 複数のチームに対してファシリテーションモードで関わる。たとえばAWS勉強会やりましょうとかナレッジベースを作るとかまだ導入されていない新技術を検証するとかテンプレート・サンプルコードを提供するとか

Slide 56

Slide 56 text

最も小さいプラットフォームは、ただのWikiかも At the same time, we're not aiming to build a massive platform. We're aiming to build what we in the book call a thinnest viable platform TVP. This TVP could be just a wiki page if that's all you need for your platform. 私たちは巨大なプラットフォームの構築を目指しているわけではありません。私たちは、書籍で「最も薄い実行可能なプラットフォーム（TVP）」と呼んでいるものを構築することを目指しています。このTVPは、プラットフォームに必要なものがウィキページだけなら、ウィキページだけで構成することも可能です。 https://teamtopologies.com/key-concepts-con tent/what-is-a-thinnest-viable-platform-tvp

Slide 57

Slide 57 text

ゴールデンパスベストプラクティスや標準化されたプロセスにより、開発チームが迷わず素早く安全にアプリケーションを開発・運用できるようにした一連のルートや仕組みのこと ● 開発者の認知負荷を減らす ● セキュリティやコンプライアンスを自然と担保する ● 開発チームがビジネス価値の創出に集中できるよう支援する例えば ● 新規サービス生成時に使えるテンプレート ● テストやCI/CDパイプラインのセットアップスクリプト ● モニタリングやログ収集などの運用機能のガイド

Slide 58

Slide 58 text

Slide 59

Slide 59 text

1:1で、コラボレーションをする Platform Teamは、まずはコラボレーションからはじめる Stream-aligned Teamと1:1になり、クラウド回りの構築・自動化を行ったり、支援ツールを作ったりする。そのStream-alignedが必要とするものを理解して作れるので、誰得なものを作り込んでしまうことを防げる開発チームその道のプロ Collaboration

Slide 60

Slide 60 text

1:1で、コラボレーションをする Platform Engineering Kaigiでの、 Manuel Paisさん(Team Topologies著者)やメルカリdeeeetさんのセッションが参考になります

Slide 61

Slide 61 text

Slide 62

Slide 62 text

そのうえで、プラットフォーム(XaaS)を作るコラボレーションモードだと、同時に関われるStream-aligned Teamは限られる。ある段階でコラボは終了し、その知見をもとにより多くのチームを助けられる疎結合な形を模索する。それがXaaSモードここではじめて、IDPの要素がでてくる開発チームその道のプロ XaaS

Slide 63

Slide 63 text

そのうえで、プラットフォーム(XaaS)を作る ● セキュアバイデフォルトなプラットフォーム ● ワンクリックで環境調達ができるポータル ● 各種ミドルウェアのオンデマンド払い出し ● 統一された認証認可 ● メトリクス収集・監視の標準セットアップ ● などなど開発チームその道のプロ XaaS 大事なことは、機能を揃えるのではなく、必要とされるものを提供すること

Slide 64

Slide 64 text

どっちがいい？プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高

Slide 65

Slide 65 text

どっちがいい？プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高プラットフォームはあるけど、開発者体験は悪い ⇨ 最悪

Slide 66

Slide 66 text

どっちがいい？プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高プラットフォームはあるけど、開発者体験は悪い ⇨ 最悪追い求めるべきは、こっち

Slide 67

Slide 67 text

だからこそ Platform Engineeringを成功させるコツはプラットフォームのことなんて忘れる開発者体験にフォーカスする

Slide 68

Slide 68 text

Platform Teamに求められること第一に、開発者体験を追い求めること第二に、　　　　　　　を作ること

Slide 69

Slide 69 text

Platform Teamに求められること第一に、開発者体験を追い求めること第二に、　　　　　　　を作ること信頼関係

Slide 70

Slide 70 text

だって信頼してないやつの押しつけうざいじゃん認知負荷を下げよう！アジリティを高めよう！ Kubernetesでプラットフォーム組んで実現！ Platform Team 言っていることは分かるけどそもそも取り組む余裕がないよ特に課題感は無いんだけど？

Slide 71

Slide 71 text

だからこそ、コラボレーションからはじめるまずは信頼関係を築くことが重要。 1:1でコラボレーションをしていくと、お互いに信頼関係が生まれるお互いに何を目指していて、何に困っているか見えるようになるそうすることで、本当に必要なものを提供できるようになるだからこそ、まずはプラットフォームなんて忘れて開発者体験向上に取り組む「役立つものを提供していたら、いつの間にかプラットフォームになっている」くらいがいい

Slide 72

Slide 72 text

だからこそ、継続が大事正論言って去って行くような形だと信頼されない『続ける』ことが何より大事 XaaSやコラボレーションを繰り返して、プラットフォームを「続ける」ことで信頼も生まれ、必要とされるものが出来ていく顧客 Platform Product プロダクトを提供プロダクトを提供プラットフォームチーム

Slide 73

Slide 73 text

Platform as a Product 顧客 Platform Product プロダクトを提供プロダクトを提供プロダクトマネージャー ● プラットフォームが最も達成したい指標は何か ○ North Star Metricsの策定 ● 顧客は何にペインを感じているのか ○ ユーザーヒアリング ● 最も重要なものから実現し、TVP(Thinnest Viable Platform)を作る ○ 実装する機能の優先順位付け ● 社内にその存在を知ってもらう ○ ブランディング、社内マーケティング

Slide 74

Slide 74 text

まとめ ● 一緒に「AWSは楽しい」とみんなが思える世界を作っていきましょう ● そのために、Platform Engineeringの考え方が役にたつかも ● プラットフォームを作るという考えに囚われず、開発者体験を高めることを大事にしよう ● プラットフォームを作らなくても、Platform Engineeringです