$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
タクシーアプリ『GO』におけるプラットフォームエンジニアリングの実践
Search
GO Inc. dev
June 28, 2024
Technology
15
12k
タクシーアプリ『GO』におけるプラットフォームエンジニアリングの実践
開発生産性Conference 2024で発表した資料です。
https://dev-productivity-con.findy-code.io/2024?m=2024/m/XmiKkhYo
GO Inc. dev
June 28, 2024
Tweet
Share
More Decks by GO Inc. dev
See All by GO Inc. dev
タクシーアプリ『GO』のリアルタイムデータ分析基盤における機械学習サービスの活用
mot_techtalk
6
2.3k
App Store Connect APIで 作業時間を増やそう
mot_techtalk
4
320
Streamlitで結合テスト工数の削減に成功した話
mot_techtalk
8
2.7k
Streamlit ホスティング基盤をどのように作ったか
mot_techtalk
4
1.1k
Streamlit ホスティング基盤をスケールさせる
mot_techtalk
4
680
実践 Advanced CallKit 〜快適な通話の実現に向けて〜
mot_techtalk
4
490
将来の機能拡張を見据えたMetricKitの実装
mot_techtalk
0
430
タクシーアプリ『GO』でのApple Pay導入
mot_techtalk
0
520
Remote notification tricks with Notification Service Extension
mot_techtalk
0
460
Other Decks in Technology
See All in Technology
店舗向けSaaSにおける 顧客要望活用の実践アプローチ(20241205_pmconf)
yujirooo
0
3.1k
Autonomous Database サービス・アップデート (FY25)
oracle4engineer
PRO
0
260
イノベーショントークから見るクラウド運用の未来を振り返ってみた
nyankotaro
0
220
12/4(水)のBedrockアプデ速報(re:Invent 2024 Daily re:Cap #3 with AWS Heroes)
minorun365
PRO
2
420
Nihonbashi Test Talk #3_WebDriver BiDiと最新の実装状況 / WebDriver BiDi latest status
takeyaqa
1
150
日本全国・都市3D化プロジェクト「PLATEAU」とデータ変換OSS「PLATEAU GIS Converter」の公開
nokonoko1203
4
360
AWS認定試験の長文問題を早く解くコツ
keke1234ke
0
170
AWS re:Invent 2024登壇資料(GBL206-JA: Unleashing the power of generative AI on AWS for your business)
minorun365
PRO
7
230
2024/11/29_失敗談から学ぶ! エンジニア向けre:Invent攻略アンチパターン集
hiashisan
0
440
241130紅白ぺぱ合戦LT「編集の技術」
toya524287
5
630
12/2(月)のBedrockアプデ速報(re:Invent 2024 Daily re:Cap #1 with AWS Heroes)
minorun365
PRO
2
310
プロダクトマネージャーは 事業責任者の夢をみるのか pmconf2024
gimupop
1
8.6k
Featured
See All Featured
Fireside Chat
paigeccino
34
3.1k
It's Worth the Effort
3n
183
27k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
23
We Have a Design System, Now What?
morganepeng
51
7.3k
Practical Orchestrator
shlominoach
186
10k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
The Cult of Friendly URLs
andyhume
78
6.1k
Side Projects
sachag
452
42k
A Philosophy of Restraint
colly
203
16k
Done Done
chrislema
181
16k
How to Ace a Technical Interview
jacobian
276
23k
Faster Mobile Websites
deanohume
305
30k
Transcript
タクシーアプリ『GO』における プラットフォームエンジニアリングの実践 2024.06.28 水戸 祐介 GO株式会社
© GO Inc. 2 自己紹介 GO株式会社 技術戦略部 部長 技術戦略部SREグループ グループマネージャ
水戸 祐介 2018年にGO株式会社の前身となるJapanTaxi株式会社に入社し、以来SREとして 継続してインフラ基盤開発や運用に携わる @y_310
© GO Inc. 今日はGOのSREが5年以上の 社内プラットフォーム導入を通して学んだ、 プラットフォームエンジニアリング実践の鍵 をお話しします 3
© GO Inc. タクシーアプリ『GO』 4
© GO Inc. 5 タクシーが呼べるアプリ『GO』 アプリから今いる場所にタクシーを呼ぶシンプルな体験を提 供しているサービス 5
© GO Inc. 6 タクシーアプリ『GO』の事業成長 『GO』自体の成長だけでなく、法人向けサービスや脱炭素化 支援事業など『GO』を中心とした 新規事業も続々と増えている状況
© GO Inc. そんな『GO』の裏側はどうなっているのか 7
© GO Inc. 『GO』の裏側 8 5年以上プラットフォームエンジニアリングを実践してたどり着いた現在地
© GO Inc. 9 『GO』の裏側 ▪ 100以上のマイクロサービスで構成 ▪ 開発者100人以上、開発チーム10以上 タクシー事業者向け
車載系 基幹系 分析系 法人向け 消費者向け ユーザーアプリ (iOS) ユーザーアプリ (Android) 配車系APIサー バ群 管理画面 ジオ・AI系サー バ群 決済系 サーバ群 GO CALL GO CALL Pro 支払請求系 サーバ群 乗務員向け アプリ 後部座席 アプリ Redash Looker GO BUSINESS 社内向け管理画面 系サーバ群 乗務員 ポータル
© GO Inc. マイクロサービスを素早く開発し、 安定運用するための様々な機能が提供 されている基盤 10 社内プラットフォームKenos マイクロサービスの大半が Kubernetesを中心としたKenosと
呼ばれる社内プラットフォームの 上で稼働
© GO Inc. 11 Kenos - クラスタ 大量のマイクロサービスを動かす 基盤となるKubernetesクラスタ マイクロサービスを構成する基本
コンポーネント ▪ APIサーバ ▪ 非同期ジョブワーカー ▪ 定期実行バッチ これらを柔軟に組み合わせてデプ ロイできる仕組みを提供 マイクロサービス APIサーバ 非同期ジョブ ワーカー 定期実行バッチ マイクロサービス APIサーバ APIサーバ マイクロサービス 非同期ジョブ ワーカー 定期実行バッチ 非同期ジョブ ワーカー 定期実行バッチ 様々なコンポーネントの組み合わせでマイクロ サービスを定義
© GO Inc. 12 Kenos - CLIツール kns 開発者が簡単にKubernetesクラスタにアクセスしてオペレーションできるよう にするためのCLIツール
マイクロサービス環境で使うことを前提にすることでシンプルな使用体験を提供して いる • 開発環境のコンテナのログを表示 • 本番環境のコンテナにログイン • 開発環境でkubectl実行環境を起動 kns dev logs kns prod connect kns dev cli Pod名指定やコンテキスト切り替えをせずにログが表示できる 環境名を変えるだけでコンテキストが切り替わり安全にコンテナに ログインできる ローカルでkubectl等がインストールされたコンテナが起動しラップさ れていないコマンドを直接実行することもできる
© GO Inc. 13 Kenos - マイクロサービステンプレート マイクロサービスをすぐに開発開始できるリポジトリテンプ レート 開発からリリースまでに必要な共通機能を予め用意しておくことで
ビジネスロジックに集中して開発ができる ▪ 基本設計 ▪ gRPC/RESTサーバフレームワーク ▪ Clean Architectureベースのディレクトリ設計とサンプルコード ▪ 社内標準ライブラリ (ロガー、暗号化など) ▪ 開発ツール ▪ makeによるビルド、テスト、実行コマンド ▪ RDB等を開発環境で起動するための docker-compose.yml ▪ flywayを使用したDBマイグレーション用のコマンド ▪ デプロイ設定 ▪ デプロイ用Dockerfile ▪ CI/CD関連の設定ファイル ▪ Kenosクラスタにデプロイするリソースの設定ファイル
© GO Inc. 14 Kenos - オブザーバビリティ基盤 Grafanaによるオブザーバビリ ティ基盤 デプロイしたマイクロサービスのメト
リクス、ログ、トレースが自動的に収 集されGrafana上で参照できる ダッシュボード、アラート一式が予め 作成されているためリリース当初から 十分にオブザーバビリティが確保され た状態で安定した運用が行える サービスによらず同じ定義でダッシュ ボードが作られているためどのサービ スを見てもすぐに状況が把握できる
© GO Inc. 15 Kenos - ワークフロー基盤 Airflowによるワークフロー基盤 多段階の複雑なバッチ処理を実行するた めの仕組み
Kenos (k8s)とAirflowを連携させること で、デプロイ設定ファイルに簡単なジョ ブ定義を記述し、ワークフロー定義 (DAG)から呼び出すだけでワークフロー を実行できる基盤 決済データの月次締め処理などで利用さ れている
© GO Inc. 16 Kenosプラットフォームの詳細 より詳細については昨年発表のこちらの資料もご覧ください タクシーアプリ「GO」の少人数SREチームとマイクロサービス基盤 https://speakerdeck.com/mot_techtalk/sre-micro-service
© GO Inc. プラットフォームエンジニアリング = プラットフォームを作ること? 17 ところで
© GO Inc. プラットフォームエンジニアリング = プラットフォームを作ること? 18 それも含むけど、必須ではない
© GO Inc. プラットフォームエンジニアリングとは サービスの非機能要件を標準化することで 開発生産性と品質を最大化する手法 19
© GO Inc. 20 プラットフォームエンジニアリングとは サービスを作る中で 「これ誰かやったことありそうなん だけどなぁ」 と思うようなものを標準化していく ことがプラットフォームエンジニア
リング 非機能要件 = 例えばデプロイの仕組み、オート スケール設定、監視ツールの設定、アカウント の権限管理など
© GO Inc. プラットフォームエンジニアリング を始めた背景 21
© GO Inc. 車輪の再発明による非効率化 AWS、GCP、Azureと3クラウドに渡って様々な方式で サービスが稼働しており、それぞれでデプロイやオー トスケール、監視、ロギングなどを個別実装していた 不十分な運用 実際にはリソース不足で作り切れないチームも多く、 運用コストが高いまま運用が続けられていることも
あった 22 技術スタックの乱立 デプロイの属人化 アラートが不足し障害に気付かない ログが柔軟に検索できず問題調査に時間がかかる など
© GO Inc. 23 SREとしての悩み ▪ 障害が起きてもどこを見れば状況が把握できるか分から ず手が出せないことが多かった ▪ 退職などでメンテナ不在になり誰も手が出せないサービ
スも存在しセキュリティ的な不安も大きかった
© GO Inc. 24 SREチームの本格始動 状況を打開するためには技術スタックの 統一が必要と判断し、SREチームを標準 化によって品質の改善と開発生産性の向 上を実現するチームとした GOのSREのミッション
止まらないサービスを 最速で作る仕組みづくり 品質 開発生産性
© GO Inc. 25 プラットフォームの開発と移行 始めは1サービスのインフラを Kubernetesに移行しプラットフォーム化 を開始 徐々にプラットフォームを改善しながら 既存サービスの移行や新規サービスへの
導入を推進 現在は大半のサービスがプラットフォー ム上で動いている状態
© GO Inc. SREチームがプラットフォームを作るの? 26 あれ?
© GO Inc. 27 GOではSREチームがプラットフォームを開発しています ▪ そもそもプラットフォームの開発を始めた2019年頃はまだプラットフォーム エンジニアリングという言葉も無かった ▪ 業務特性の面から当面SREとプラットフォーム開発は分離しない予定
SRE Platform 日々のインフラ監視 インフラ構築 定常業務の自動化、など プラットフォーム開発 標準化 ツール開発、など Devよりの業務 Opsよりの業務 分離するとDev vs Opsな Before DevOps時代的構造に なってしまうリスク Opsの実践による課題発見がDevの業務の元に なることも多く簡単に線引きできない側面も
© GO Inc. プラットフォームエンジニアリングを 5年以上実践してきた 振り返ると、いくつか成否を分ける 重要なポイントがあった 28
© GO Inc. プラットフォームエンジニアリング 実践の鍵 29
© GO Inc. 30 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪
サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
© GO Inc. 開発者 ビジネスロジックの実装 SRE 非機能要件全般の標準化とツールの開発、 インフラの構築 31 責任境界を高いラインに設定
インフラだけでなくアプリケーションまで踏み 込んで標準化することで品質と生産性を担保 例えば リポジトリテンプレートを提供することでサーバとしての基本動作を担保し、 運用品質を上げている
© GO Inc. 32 責任境界を高いラインに設定 アプリケーションの非機能要件までを責任範囲とした理由 標準化可能な領域を全て標準化しようとした結果 その名の通り、サービス固有のロジックなので標準化はできない サービスに依存しないロジックなので標準化しやすい インフラの上でどんなアプリケーションが動いている
かはあまり関係がないので標準化しやすい 例: 注文処理、決済処理、ユーザ情報の管理など 例: デプロイ、ロギング、設定値の管理、サーバの起動終了、通信プロトコルなど 例: ロードバランサー、k8sのDeployment、DBの基本設定、S3などのクラウドリソースのパラメータ
© GO Inc. 33 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪
サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
© GO Inc. AWSやGCP上のインフラ構築は全てSREが実施 34 インフラ構築作業をSREがすべて巻き取る インフラ構築責務の2つのパターン SREチームが構築 開発チームが共通モジュール を使って自ら構築
プラットフォームエンジニアリングの文脈ではこちらが推奨 されている模様 GOではあえてこちらを採用している
© GO Inc. 35 インフラ構築作業をSREがすべて巻き取る 高いレベルの標準化をするため 標準化は1回で最適解にたどり着けるわけではなく継続的な改善が必要なため、改善が進みやす い方法を選んだ
© GO Inc. SREチームの業務が増えすぎるのではないか? ▪ 始めて最初の2,3年は標準化されていないことばかりで負担は大きかった ▪ 諦めずに標準化を続けることで徐々に楽になっていった 36 インフラ構築作業をSREがすべて巻き取る
© GO Inc. 37 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪
サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
© GO Inc. 38 サービスのアーキテクチャレビューを行う 標準の維持が一番の目的 ▪ 標準を全て言語化、仕組み化するのは難しい ▪ レビューを通して、同じ課題は同じ方法で解決するように設計を修
正し、パターンが発散していくのを抑止している 開発チームのアーキテクチャ設計をSREが必ずレビュー 例えば MemcachedやRDBが悪いわけではなく、同じ課題を解決するのに違う方法を使わないことを重視 標準の選択肢で解決できない課題に対して別の技術を使うことは厭わない
© GO Inc. 39 サービスのアーキテクチャレビューを行う 標準に揃えることにこだわる理由 どんなものでも作った後に問題は起き、解決していく必要がある 持続的に品質を維持するには、発生する問題のパターンを収束させ問題解決のコ ストを最小化する必要がある 問題の種類が発散し個別解決が必要になる
一箇所で問題を解決すれば他の場所にも水平展開できる (問題がまだ起きていない場所では未然に解決もできる) 同じ課題を違う方法で実装すると 同じ課題を同じ方法で実装すると
© GO Inc. 40 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪
サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
© GO Inc. 41 完璧なプラットフォームを目指さない 実際に発生している課題を解決する GOではプラットフォームの長期ロードマップは 持たず、常に次の半年に作るものだけを決めてプ ラットフォームを改善してきた 次の半年の開発目標設定
半年で開発してリリース 最新の課題を収集 作っているのはあくまで社内プラットフォーム 世の中で一般的にニーズがある機能でも社内に ニーズが無いなら作る意味がない 場当たり的な拡張ではなく、疎結合なコンポーネントの積み 上げによって長期プラン無しでも拡張性を維持している
© GO Inc. 42 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪
サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
© GO Inc. 43 開発者の課題解決が最優先 プラットフォームの既存機能やポリシーでは対応できない要望が 来ても開発者の課題解決を最優先に動く 要望の根幹にある解決し たい課題を理解する 負債になりづらい暫定案
を考える 開発者の課題を解決する 要望そのものではなく本質的に何 が解決されればよいのかを考える 単なるその場しのぎではなく、後 からやり直しやすい方法を探す 開発者の課題はスケジュール内に 解決し、プラットフォームの課題 は後から解決する 開発者の行き止まりを作らない事が重要 一方でプラットフォームの将来性を犠牲にする安易な例外対応は避ける
© GO Inc. プラットフォームエンジニアリングの成果 44
© GO Inc. 45 アクティブな開発 プラットフォーム上のサービス全体で 平均して毎週20サービスが45回以上本番環境にデプロイしている
© GO Inc. 46 開発者によるサービス運用 自動化とオブザーバビリティを充実させることで開発者自身 による運用を実現 SREチーム 開発チーム デプロイ、ロールバック
アラート一次対応 アプリケーション起因の問題対応 障害発生時の開発者サポート インフラ起因の問題対応 難易度が高い性能問題等の調査 SREチームは各サービスのオンコールには入らない (大規模なエラー発生時にのみSREの電話も鳴る設定)
© GO Inc. 47 新機能の水平展開 プラットフォームに追加した機能はどのサービスでも容易に使える あるチームで生まれた課題によって生まれた機能が他のチームでも使われるため改 善の投資対効果が高い 開発チームの要望で追加された機能の例 ▪
featureブランチから動的に環境を作る機能 ▪ GitHubのリリースノート自動作成 ▪ ローカル開発用シークレットを暗号化してリ ポジトリに保存する機能 ▪ gRPCテスト用Web UI (grpcui)の標準搭載
© GO Inc. 48 インフラ構築の効率化 標準化により効率的にインフラ構築が行える ▪ インフラ構築の依頼数 ▪ 毎月平均1,2マイクロサービスの新規構築
▪ 毎週数回既存サービスの構成変更 負担はあるが対応可能なレベルに収まっている ▪ 最短リードタイム1日程度で新規構築可能 ▪ 既存サービスの構成変更は数十分程度で終わるものが大半 ▪ インフラ構築工数を厳密に計画せずに、オンデマンドの対応で吸収できている状態 インフラ構成と構築手順の標準化によって高い効率で構築作業が行えている
© GO Inc. 49 SRE業務の生産性向上 サービス構成が一貫していることで、SREチームがレバレッジ効果 の高い仕事ができる 全マイクロサービスへの変更が必要な大規模なツールの導入を開発者への依頼無しで達成 ▪ 全マイクロサービスのCI/CDをTravis
CIからGitHub Actionsに ▪ 全リポジトリのCI設定を書き換え ▪ オブザーバビリティ基盤をNew RelicからGrafanaに ▪ 全サービスのダッシュボードやアラートを書き換え ▪ マイクロサービスへのOpenTelemetryベースのトレースの導入 ▪ 大量のサービスでOpenTelemetryライブラリを使った実装を追加
© GO Inc. 50 SRE業務の生産性向上 サービス構成が一貫していることで、SREチームがレバレッジ効果 の高い仕事ができる どのマイクロサービスであっても一般的なオペレーションや構築作業は同じ手順で行える仕 組みになっているため、サービスによらずSRE全員が対応可能となっており、属人性が低い 運用が行えている
• 新規マイクロサービスの構築 • RDSやS3といったクラウドリソースの追加 • 障害時のロールバックや再起動 • ログの調査 属人性の軽減
© GO Inc. 51 SRE業務の生産性向上 サービス構成が一貫していることで、SREチームがレバレッジ効果 の高い仕事ができる ここまでご紹介したプラットフォーム開発、運用、インフラ構築、開発者サポー トなどは全て5名のSREチームで行っている 少人数チーム
© GO Inc. まとめ 52
© GO Inc. 53 まとめ プラットフォームエンジニアリングは持続的な標準化の営み プラットフォームエンジニアリングの実践を通して学んだこと プラットフォームのような特定の成果物を作ることではなく、 様々な状況に対応しながら 標準化という手法で
継続的に品質と開発生産性の向上を目指す活動
© GO Inc. 54 お知らせ ▪ GO株式会社では、共に働く仲間を募集中 です ▪ 今日お話した開発環境が気になった方はぜひ
一度採用サイトをのぞいてみてください ▪ 技術情報はXにて@goinc_techtalkで 発信しています ▪ 展示エリアでブースも出展しています ▪ エンジニアが参加しておりますので、お気軽 にお立ちよりください 採用サイトはこちら↑ https://goinc.jp/career/
© GO Inc. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください