🎃
Platform Engineering Meetup #2 に参加なぅ
とりあえず参加したのでメモを雑に残します、本当にただのメモ
きっと今日の発表はどこかで資料が上がると思うので殴り書き
Platform Engineering at Mercari
- @deeeet さん
- mercari の Platform Engineering の director
- 会場知り合いばかりでやりづらいとのこと
- 僕はあんまり知ってる人いないなぁ〜〜ｗ
- Overview of Mercari Developer Platform
- ミッション
- メリカリグループの開発者がお客様に対してより良い体験を素早く提供したりサポートしたりすることをミッションとしている
- 対象はメルカリグループの全ての開発者
- Mercari, メルペイ、Mercoin、US などなど
- 全体像
- 開発者がアプリケーションリリースして、運用を行うまでに必要な全部をやっている
- Interface
- Build
- Test
- Deploy
- Operate
- インフラからネットワーク、Data Pipeline まで本当に全部っぽい
- それぞれの領域に専属チームを作って専門性の高い状態を作っている
- 開発者がアプリケーションリリースして、運用を行うまでに必要な全部をやっている
- ミッション
- Platform を構築した中で得られたことの共有
- Business as Fast Priority
- ビジネスを最重要視して考える
- ビジネスが成功しないと意味がない
- ビジネス成功をちゃんと駆動できる Internal Platfrom
- ビジネスを最重要視して考える
- Platform as Product
- Internal の 開発者用ツールであってもプロダクトの一つとして開発をしていく
- Customer のニーズを理解して開発していく
- Platform を Project として開発することは Bad Practice
- 継続的にメンバーをアサインしてメンテナンスと改善を行う
- 開発者のニーズを理解して本当に必要なことを作っていくことで使ってもらえないということに楔を打つ
- Product Management 的なことをしっかりやること
- Discovery
- Prioritization
- Validation
- この3つを継続的に回していく
- Internal の 開発者用ツールであってもプロダクトの一つとして開発をしていく
- Start from "Collaboration"
- Team Topologies という本に詳しく載っている
- Platform Team は複数の Stream Alined Teams に対して X-as-a-Service として活動
- Collaboration -> Establish -> X-as-a-Service
- このプロセスをやることが一番手っ取り早い
- Collaboration として一緒に働いてしまえば現場の課題に直面し、解像度高く活動できる
- 改善のループを回すことで横展開をしやすくなりそれほど的外れなものを作らなくて良くなる
- Collaboration -> Establish -> X-as-a-Service
- Stream-Alined チームと適切な距離感を持つ
- Collaboration Team 的な働き方をするとより近くになろうとする力が働く
- Platform Team をそのチームに取り入れようとして抜け出せなくなるパターン
- そのチーム専用のチームになってしまう
- 意図的に離れるための力を働かせること
- 離れることの期限を決める
- 日付でもいいしプロジェクトの終わりでもいい
- X-as-a-Service になる未来を考える
- 将来的に Platform に載せるためにはどうしたらいいかを考えながら適用する
- やらないことを明確に決める
- オンコールだけはやらない、とか
- 離れることの期限を決める
- Collaboration Team 的な働き方をするとより近くになろうとする力が働く
- Stream-Alined から離れて行った結果
- 距離ができてしまう
- 課題がわからなくなったり
- Platform Team がどうゆう課題を持っていくべきなのかがわからなくなってしまって継続的な改善ができなくなってしまう
- 意図的に開発チームに関わりに行く
- 社内勉強会やブログ等
- 直接質問や課題を受け付けるチャンネルを作る
- 週一で Office Hour という時間を作る
- 定期的に Developer Survey をやって課題を吸収する
- 距離ができてしまう
- Business as Fast Priority
- Platform Engineering = Migration Engineering
- Platform を長くやっていながら思うのはずっと Migration してる
- 古いインフラを新しい基盤に載せ替える
- 基盤上で新しい機能を提供してそれをつかってもらう
- 色々やってきたけど一番時間がかかったのは Migration だそうで
- Migration が大事な理由
- Migration しないと似たようなツールが量産されてどんどん使われなくなる
- Migration をちゃんとすると社内ツールの数を集約することができる
- みんなが同じツールを使うことになるのでその改善によって社内全部に展開できる
- Migration をちゃんとすると社内ツールの数を集約することができる
- Migration しないと似たようなツールが量産されてどんどん使われなくなる
- X-as-a-Service 担ってしまったものを Migration するのは非常に大変
- Migration をするためには Stream-alined Team と合意形成をして進める必要がある
- Migration の成功の Tips
- Migration をすることを前提に設計する
- Stream-Alined と Collaboration することから始める
- Cost をとにかく最小にすること
- ドキュメントを作ることはもちろん
- スクリプトなどで自動化する
- Communication に尽きる
- Platform を長くやっていながら思うのはずっと Migration してる
AI 開発への未来へ備えよ！Platform Engineering と GitHub を使った開発
Yuki Hattori@yuhattor さん
- Platform エンジニアリングは Platform をプロダクトとして扱う
- プロジェクトとプロダクトの違い
- 期限が決まっているかどうか
- プロダクト
- 主要顧客は社内のエンジニア
- 作るべきもの
- ○ 顧客が望む最適なプラットフォーム
- ｘ 俺が考える最強のプラットフォーム
- インフラを作るだけだと片手落ちになる可能性がある
- プラットフォーム提供後の運用が重要
- ユーザーは無限の欲求を持っている
- 間違えると
- プラットフォームチームが認知や運用の負荷を全て受け付ける
- プラットフォームをプラットフォームチームに押し付ける
- インナーソース
- オープンソースの原則を社内のソフトウェア開発に適用すること
- ちゃんと手元で開発してもらったものを共有してもらう
- 車輪の再発明みたいなのがなくなったりする
- インナーソースはプラットフォームの運用を「自律的なもの」にする鍵
- 日本でもコミュニティがある
- Openness
- オープｊンなプロジェクト
- Transparency
- 透明性
- Prioritized Mentorship
- 優先的なメンターシップ
- Voluntary Code Contribution
- 自発的なコードコントリビューション
- Openness
-
インナーソースパターンブック
- あとで読む
- MS でもフレームワークを公開している
- オープンソースの原則を社内のソフトウェア開発に適用すること
- Github 上でのコラボレーションを加速させ、安定させる
- 開発環境の統一化に役立つ Github ツール
- Github Codespaces
- Github Actions ARC
- Actions Runner Controller Public Beta
- 開発環境の統一化に役立つ Github ツール
- プロジェクトとプロダクトの違い
- Platform Engineering を AI でどうやって加速するのか
- Github Copilot の活躍領域の例
- 自然言語
- コメント to Code (テンプレーティングを含む)
- コメント to Code (リファクタリング・微調整)
- ドキュメント to Code
- コーディング
- 日々のコーディングの補完
- 繰り返し・定型的な作業
- 専門技術・ハイコンテキストな領域におけるコーディング支援
- 調査・デバッグ・最適化
- ドキュメントリーディング・検索作業の置き換え
- デバッグ・リファクタリング
- チューニング
- AI が仕事を奪うというのはまだ先のようだ
- Github Copilot は魔法のようだがスキルも必要
- 日々のエンジニアリング効率化で大幅な時間節約は可能
- コンテキストが全て
- 経験や知識が豊富なエンジニアはさらに。。。
- 精度の高い提案のためには AI が読めるファイルである必要がある
- 裏で .csv で開いているだけで一瞬でコードか
- ビジネスサイドも PPT や Excel ではなく Markdown や CSV で保持する必要性
- 個人の開発が変わる -> 組織の開発も変わらなければいけない
- コンテキストレスな設計
- API/ライブラリモジュール化やパッケージ化
- Terraform のモジュール化
- システムのマイクロサービス化
- 自然言語
- Github Copilot X
- 開発プロセスに AI が入る
- Github Copilot for PR
- Github Copilot for Docs
- 開発プロセスに AI が入る
- Copilot との協業はエンジニアだけにとどまらない
- Github Copilot の活躍領域の例
- まとめ
- プラットフォームエンジニアリングに Github のツールを活用しよう
- プラットフォームを自律的に反映させるためにはインナーソースが鍵
- AI と協業できるような開発スタイルを (チームとして作っていこう)
IaaSにおけるPlatform Engineeringとこれから(仮
@kazeburo さん
- さくらのクラウド開発の課題
- これまでの10年を次の10年につなぐ
- 既存のデータセンター・インフラ運用の維持継続
- IaaS コアシステムを現代化、技術水準の向上
- クラウドとして価値向上に
- 高信頼とデリバリのパフォーマンスを両立
- SRE/Platform Engineering
- 2022 年7月に SRE 室を設立
- 現在はメンバー5名
- SRE の取り組みがより評価されることを目的に発足
- これまでの10年を次の10年につなぐ
- 現在進行中の取り組み
- k8s 基盤
- 社内(プライベート)ネットワークに接続された「さくらのクラウド」上に開発者が k8s クラスタを構築できる基盤
- Cluster API ベースで開発
- マニフェストを元に構築
- 社内での k8s 運用課題の洗い出し
- 社内において幾つかのチームで独自にクラスタを運用
- さくらのクラウド上、物理サーバ上など環境は様々
- トラブル時の運用、クラスタのアップデートなどの課題は共通
- 課題をヒアリングから洗い出し、基盤開発へのフィードバック
- 社内において幾つかのチームで独自にクラスタを運用
- 社内 k8s 運営コミュニティの開始
- SKOG の発足
- Slack や オンライン勉強会など
- 社内 k8s への要望
- インターネットからのリーチャビリティ
- マルチリージョンの冗長性確保
- これらが課題となりあまり使われなかった
- 期待値のずれ
- 開発者はアプリケーション実行基盤が欲しい
- 基盤の利用は一部に限られている状態
- 今後はアプリケーションを動作させることに集中したい
- Namespace によるマルチテナント
- 社外からのトラフィックを受付
- 堅牢性向上/東京・石狩での冗長性の確保
- ログ、メトリクス永続化の組み込み
- セルフサービスに基づいたポリシー
- どこまでをやってどこをやらないか
- Sakura monitoring suite
- Observability を支える課題
- 長期間のデータを格納するため大規模なストレージが必要
- 効果養成の担保、複雑なクラスタの運用
- 定期アップデートなどのメンテナンス
- 開発者に求めるには大きな負担になる
- Observability を実現する際の開発者にとっての負担を軽減
- monitoring Suite ではメトリクスとログを提供している
- メトリクス
- Prometheus の Remote Storage を提供
- アルファ版として提供中
- バックボーンネットワークの可視化
- エンハンスド DB
- Prometheus の Remote Storage を提供
- ログ
- アクセスログや構造化ログに対して高速にクエリ
- 低コストで運用の実現、スケールするサービスを目指し開発中
- 開発者のニーズを捉えていくための Demo を重要視
- Observability を支える課題
- Agile Culture の育成
- Enabling SRE を通した文化の育成
- さくらのクラウドのアプライアンス開発・運用に課題
- ISSUE やお客様からの問い合わせに遅延、など
- チームビルディングから SRE 活動をしている
- オンラインでの朝・夕会、定例の開催
- 特定の個人に頼らない ISSUE・障害対応
- Blameless な振り返り
- ドキュメンテーション文化
- ロードマップの作成
- さくらのクラウドのアプライアンス開発・運用に課題
- 今後
- Observability の向上
- Sakura Monitoring Suite の活用
- SLI/SLO の策定
- 高信頼の価値提供
- 自律的なチームへ
- Reading Club on Team Building
- SRE 室と開発チームのリーダーで開催
- Observability の向上
- Enabling SRE を通した文化の育成
- k8s 基盤
- まとめ
- IaaS における Platform Engineering とこれから
- システムと文化の両面で高信頼のクラウドを支える
- Dev と Ops/ Dev と SREs の両面で
- IaaS における Platform Engineering とこれから
Platform Team と 社内政治 〜 出でよ、Platform Champion 〜
@kenojiri さん
- Platform Team を護る者
- ちょっと広い視野で Platform を見てみる
- アプリの日々の開発運用を支える Platform
- アプリは現場のビジネスを支える
- 人々同士の関わりに着目して Platform Team がどうゆう立ち位置に置かれがちなのか
- Platform Team は。。。
- 結成、運用時
- 様々な期待を得て意気揚々と仕事を始める
- 結成、運用時
- Platform Team は辛いよ
- 増えるアプリチーム
- 容赦なく変わるポリシー
- 双方の要望や指示に忙殺されて疲弊していく
- やらかしたら。。
- 様々なところから叩かれる
- アプリチームからは見放され
- 失敗の落胤を押される
- ただ、全てのアプリチームが抜けるまで泣く泣くやっていくしかない
- 様々なところから叩かれる
- こんな悲しいことにならないために Platform Chanpion
- Platform as Product を進める際に Platform Team を育て守っていく
- ちょっと広い視野で Platform を見てみる
- Platform チームを何から護るか
- 舞台設定
- とあるオンライン運営会社
- 核開発運営チームは独立採算制
- Platform コストはアプリ実行にかかる CPU・Memory の利用割合に応じて各チームに配賦
- シーン１ 「板挟み」
- CI パイプラインにコンテナイメージの脆弱性スキャンを導入して DevSec Ops を強化
- 開発完了からリリースまでにかかるリードタイムが増大、開発運営チームから「遅い」「厳しい」と苦情殺到
- CI実行にかかるコンピューティングコストが上昇、経営陣からコスト削減圧力
- 社内政治を突破するために Platform Chanpion に頑張って欲しい
- CI パイプラインにコンテナイメージの脆弱性スキャンを導入して DevSec Ops を強化
- シーン２ 「変わるポリシー」
- 特定のゲームだけやたらとインターネット通信が発生することが判明、回線コストが上昇
- 他チームから「コスト配布が不平等」と苦情殺到
- 経営層の指示により回線コストを通信量従量制で配布するポリシーに見直すことに
- ポリシーの説明や配賦実施は勘弁して欲しい
- 特定のゲームだけやたらとインターネット通信が発生することが判明、回線コストが上昇
- シーン３ 「強権発動」
- あるチームの要望に応じた Platform 機能を有声んして実装することが露呈
- 他チームから 「えこひいき」 「説明しろ」 と苦情殺到
- Platform Team の一存か？
- 経営陣からの指示によるのか？
- 他チームから 「えこひいき」 「説明しろ」 と苦情殺到
- あるチームの要望に応じた Platform 機能を有声んして実装することが露呈
- とあるオンライン運営会社
- Platform Team の便利屋化から護る
- Platform team 外の人たちが勘違いしがち
- Platform Team の強権化から護る
- Platform teaｍ 自体が勘違いしがち
- 舞台設定
- Platform Chanpion に何を求める？
- Platform Chanpion に求められる者
- CxO クラスに物申せる社内政治力
- プロダクトとしての Platform と Platform Team の成長と成熟を見守る親心
- Platform Team に強権を持たせないバランス感覚
- Platform Engineering は農業のごとし
- いい土地、苗、だけではよくならない
- 天災や人災なども
- 5年、10年、20年の中長期的な視野を持っていく
- Platform Chanpion に求められる者
- おわりに
- 難題を抱え込むな
- 技術的な難題なら上に相談して外の力を借りよう
- そうでないなら君たちが解くべき難題ではない
- 天狗になるな
- スキルは会社全体の未来のために
- admin 権限 ≠ 政治力の源泉、その権限はみんなの負託
- 難題を抱え込むな
Discussion