タクシーアプリ『GO』におけるプラットフォームエンジニアリングの実践

開発生産性Conference 2024で発表した資料です。
https://dev-productivity-con.findy-code.io/2024?m=2024/m/XmiKkhYo

Transcript

1. タクシーアプリ『GO』における プラットフォームエンジニアリングの実践 2024.06.28 水戸 祐介 GO株式会社
2. © GO Inc. 2 自己紹介 GO株式会社 技術戦略部 部長 技術戦略部SREグループ グループマネージャ 水戸 祐介 2018年にGO株式会社の前身となるJapanTaxi株式会社に入社し、以来SREとして 継続してインフラ基盤開発や運用に携わる @y_310
3. © GO Inc. 今日はGOのSREが5年以上の 社内プラットフォーム導入を通して学んだ、 プラットフォームエンジニアリング実践の鍵 をお話しします 3
4. © GO Inc. タクシーアプリ『GO』 4
5. © GO Inc. 5 タクシーが呼べるアプリ『GO』 アプリから今いる場所にタクシーを呼ぶシンプルな体験を提 供しているサービス 5
6. © GO Inc. 6 タクシーアプリ『GO』の事業成長 『GO』自体の成長だけでなく、法人向けサービスや脱炭素化 支援事業など『GO』を中心とした 新規事業も続々と増えている状況
7. © GO Inc. そんな『GO』の裏側はどうなっているのか 7
8. © GO Inc. 『GO』の裏側 8 5年以上プラットフォームエンジニアリングを実践してたどり着いた現在地
9. © GO Inc. 9 『GO』の裏側 ▪ 100以上のマイクロサービスで構成 ▪ 開発者100人以上、開発チーム10以上 タクシー事業者向け 
 車載系
 基幹系
 分析系
 法人向け
 消費者向け
 ユーザーアプリ 
 (iOS)
 ユーザーアプリ (Android)
 配車系APIサー バ群
 管理画面
 ジオ・AI系サー バ群
 決済系
 サーバ群
 GO CALL
 GO CALL Pro 
 支払請求系 
 サーバ群
 乗務員向け アプリ
 後部座席
 アプリ
 Redash
 Looker
 GO BUSINESS 
 社内向け管理画面 系サーバ群 
 乗務員
 ポータル

10. © GO Inc. マイクロサービスを素早く開発し、 安定運用するための様々な機能が提供 されている基盤 10 社内プラットフォームKenos マイクロサービスの大半が Kubernetesを中心としたKenosと 呼ばれる社内プラットフォームの 上で稼働
11. © GO Inc. 11 Kenos - クラスタ 大量のマイクロサービスを動かす 基盤となるKubernetesクラスタ マイクロサービスを構成する基本 コンポーネント ▪ APIサーバ ▪ 非同期ジョブワーカー ▪ 定期実行バッチ これらを柔軟に組み合わせてデプ ロイできる仕組みを提供 マイクロサービス APIサーバ 非同期ジョブ ワーカー 定期実行バッチ マイクロサービス APIサーバ APIサーバ マイクロサービス 非同期ジョブ ワーカー 定期実行バッチ 非同期ジョブ ワーカー 定期実行バッチ 様々なコンポーネントの組み合わせでマイクロ サービスを定義
12. © GO Inc. 12 Kenos - CLIツール kns 開発者が簡単にKubernetesクラスタにアクセスしてオペレーションできるよう にするためのCLIツール マイクロサービス環境で使うことを前提にすることでシンプルな使用体験を提供して いる • 開発環境のコンテナのログを表示 • 本番環境のコンテナにログイン • 開発環境でkubectl実行環境を起動 kns dev logs kns prod connect kns dev cli Pod名指定やコンテキスト切り替えをせずにログが表示できる 環境名を変えるだけでコンテキストが切り替わり安全にコンテナに ログインできる ローカルでkubectl等がインストールされたコンテナが起動しラップさ れていないコマンドを直接実行することもできる
13. © GO Inc. 13 Kenos - マイクロサービステンプレート マイクロサービスをすぐに開発開始できるリポジトリテンプ レート 開発からリリースまでに必要な共通機能を予め用意しておくことで ビジネスロジックに集中して開発ができる ▪ 基本設計 ▪ gRPC/RESTサーバフレームワーク ▪ Clean Architectureベースのディレクトリ設計とサンプルコード ▪ 社内標準ライブラリ (ロガー、暗号化など) ▪ 開発ツール ▪ makeによるビルド、テスト、実行コマンド ▪ RDB等を開発環境で起動するための docker-compose.yml ▪ flywayを使用したDBマイグレーション用のコマンド ▪ デプロイ設定 ▪ デプロイ用Dockerfile ▪ CI/CD関連の設定ファイル ▪ Kenosクラスタにデプロイするリソースの設定ファイル
14. © GO Inc. 14 Kenos - オブザーバビリティ基盤 Grafanaによるオブザーバビリ ティ基盤 デプロイしたマイクロサービスのメト リクス、ログ、トレースが自動的に収 集されGrafana上で参照できる ダッシュボード、アラート一式が予め 作成されているためリリース当初から 十分にオブザーバビリティが確保され た状態で安定した運用が行える サービスによらず同じ定義でダッシュ ボードが作られているためどのサービ スを見てもすぐに状況が把握できる
15. © GO Inc. 15 Kenos - ワークフロー基盤 Airflowによるワークフロー基盤 多段階の複雑なバッチ処理を実行するた めの仕組み Kenos (k8s)とAirflowを連携させること で、デプロイ設定ファイルに簡単なジョ ブ定義を記述し、ワークフロー定義 (DAG)から呼び出すだけでワークフロー を実行できる基盤 決済データの月次締め処理などで利用さ れている
16. © GO Inc. 16 Kenosプラットフォームの詳細 より詳細については昨年発表のこちらの資料もご覧ください タクシーアプリ「GO」の少人数SREチームとマイクロサービス基盤 https://speakerdeck.com/mot_techtalk/sre-micro-service
17. © GO Inc. プラットフォームエンジニアリング = プラットフォームを作ること？ 17 ところで
18. © GO Inc. プラットフォームエンジニアリング = プラットフォームを作ること？ 18 それも含むけど、必須ではない
19. © GO Inc. プラットフォームエンジニアリングとは サービスの非機能要件を標準化することで 開発生産性と品質を最大化する手法 19
20. © GO Inc. 20 プラットフォームエンジニアリングとは サービスを作る中で 「これ誰かやったことありそうなん だけどなぁ」 と思うようなものを標準化していく ことがプラットフォームエンジニア リング 非機能要件 = 例えばデプロイの仕組み、オート スケール設定、監視ツールの設定、アカウント の権限管理など
21. © GO Inc. プラットフォームエンジニアリング を始めた背景 21
22. © GO Inc. 車輪の再発明による非効率化 AWS、GCP、Azureと3クラウドに渡って様々な方式で サービスが稼働しており、それぞれでデプロイやオー トスケール、監視、ロギングなどを個別実装していた 不十分な運用 実際にはリソース不足で作り切れないチームも多く、 運用コストが高いまま運用が続けられていることも あった 22 技術スタックの乱立 デプロイの属人化 アラートが不足し障害に気付かない ログが柔軟に検索できず問題調査に時間がかかる など
23. © GO Inc. 23 SREとしての悩み ▪ 障害が起きてもどこを見れば状況が把握できるか分から ず手が出せないことが多かった ▪ 退職などでメンテナ不在になり誰も手が出せないサービ スも存在しセキュリティ的な不安も大きかった
24. © GO Inc. 24 SREチームの本格始動 状況を打開するためには技術スタックの 統一が必要と判断し、SREチームを標準 化によって品質の改善と開発生産性の向 上を実現するチームとした GOのSREのミッション 止まらないサービスを 最速で作る仕組みづくり 品質 開発生産性
25. © GO Inc. 25 プラットフォームの開発と移行 始めは1サービスのインフラを Kubernetesに移行しプラットフォーム化 を開始 徐々にプラットフォームを改善しながら 既存サービスの移行や新規サービスへの 導入を推進 現在は大半のサービスがプラットフォー ム上で動いている状態
26. © GO Inc. SREチームがプラットフォームを作るの？ 26 あれ？
27. © GO Inc. 27 GOではSREチームがプラットフォームを開発しています ▪ そもそもプラットフォームの開発を始めた2019年頃はまだプラットフォーム エンジニアリングという言葉も無かった ▪ 業務特性の面から当面SREとプラットフォーム開発は分離しない予定 SRE Platform 日々のインフラ監視 インフラ構築 定常業務の自動化、など プラットフォーム開発 標準化 ツール開発、など Devよりの業務 Opsよりの業務 分離するとDev vs Opsな Before DevOps時代的構造に なってしまうリスク Opsの実践による課題発見がDevの業務の元に なることも多く簡単に線引きできない側面も
28. © GO Inc. プラットフォームエンジニアリングを 5年以上実践してきた 振り返ると、いくつか成否を分ける 重要なポイントがあった 28
29. © GO Inc. プラットフォームエンジニアリング 実践の鍵 29
30. © GO Inc. 30 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪ サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
31. © GO Inc. 開発者 ビジネスロジックの実装 SRE 非機能要件全般の標準化とツールの開発、 インフラの構築 31 責任境界を高いラインに設定 インフラだけでなくアプリケーションまで踏み 込んで標準化することで品質と生産性を担保 例えば リポジトリテンプレートを提供することでサーバとしての基本動作を担保し、 運用品質を上げている
32. © GO Inc. 32 責任境界を高いラインに設定 アプリケーションの非機能要件までを責任範囲とした理由 標準化可能な領域を全て標準化しようとした結果 その名の通り、サービス固有のロジックなので標準化はできない サービスに依存しないロジックなので標準化しやすい インフラの上でどんなアプリケーションが動いている かはあまり関係がないので標準化しやすい 例: 注文処理、決済処理、ユーザ情報の管理など 例: デプロイ、ロギング、設定値の管理、サーバの起動終了、通信プロトコルなど 例: ロードバランサー、k8sのDeployment、DBの基本設定、S3などのクラウドリソースのパラメータ
33. © GO Inc. 33 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪ サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
34. © GO Inc. AWSやGCP上のインフラ構築は全てSREが実施 34 インフラ構築作業をSREがすべて巻き取る インフラ構築責務の2つのパターン SREチームが構築 開発チームが共通モジュール を使って自ら構築 プラットフォームエンジニアリングの文脈ではこちらが推奨 されている模様 GOではあえてこちらを採用している
35. © GO Inc. 35 インフラ構築作業をSREがすべて巻き取る 高いレベルの標準化をするため 標準化は1回で最適解にたどり着けるわけではなく継続的な改善が必要なため、改善が進みやす い方法を選んだ
36. © GO Inc. SREチームの業務が増えすぎるのではないか？ ▪ 始めて最初の2,3年は標準化されていないことばかりで負担は大きかった ▪ 諦めずに標準化を続けることで徐々に楽になっていった 36 インフラ構築作業をSREがすべて巻き取る
37. © GO Inc. 37 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪ サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
38. © GO Inc. 38 サービスのアーキテクチャレビューを行う 標準の維持が一番の目的 ▪ 標準を全て言語化、仕組み化するのは難しい ▪ レビューを通して、同じ課題は同じ方法で解決するように設計を修 正し、パターンが発散していくのを抑止している 開発チームのアーキテクチャ設計をSREが必ずレビュー 例えば MemcachedやRDBが悪いわけではなく、同じ課題を解決するのに違う方法を使わないことを重視 標準の選択肢で解決できない課題に対して別の技術を使うことは厭わない
39. © GO Inc. 39 サービスのアーキテクチャレビューを行う 標準に揃えることにこだわる理由 どんなものでも作った後に問題は起き、解決していく必要がある 持続的に品質を維持するには、発生する問題のパターンを収束させ問題解決のコ ストを最小化する必要がある 問題の種類が発散し個別解決が必要になる 一箇所で問題を解決すれば他の場所にも水平展開できる (問題がまだ起きていない場所では未然に解決もできる) 同じ課題を違う方法で実装すると 同じ課題を同じ方法で実装すると
40. © GO Inc. 40 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪ サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
41. © GO Inc. 41 完璧なプラットフォームを目指さない 実際に発生している課題を解決する GOではプラットフォームの長期ロードマップは 持たず、常に次の半年に作るものだけを決めてプ ラットフォームを改善してきた 次の半年の開発目標設定 半年で開発してリリース 最新の課題を収集 作っているのはあくまで社内プラットフォーム 世の中で一般的にニーズがある機能でも社内に ニーズが無いなら作る意味がない 場当たり的な拡張ではなく、疎結合なコンポーネントの積み 上げによって長期プラン無しでも拡張性を維持している
42. © GO Inc. 42 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪ サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
43. © GO Inc. 43 開発者の課題解決が最優先 プラットフォームの既存機能やポリシーでは対応できない要望が 来ても開発者の課題解決を最優先に動く 要望の根幹にある解決し たい課題を理解する 負債になりづらい暫定案 を考える 開発者の課題を解決する 要望そのものではなく本質的に何 が解決されればよいのかを考える 単なるその場しのぎではなく、後 からやり直しやすい方法を探す 開発者の課題はスケジュール内に 解決し、プラットフォームの課題 は後から解決する 開発者の行き止まりを作らない事が重要 一方でプラットフォームの将来性を犠牲にする安易な例外対応は避ける
44. © GO Inc. プラットフォームエンジニアリングの成果 44
45. © GO Inc. 45 アクティブな開発 プラットフォーム上のサービス全体で 平均して毎週20サービスが45回以上本番環境にデプロイしている
46. © GO Inc. 46 開発者によるサービス運用 自動化とオブザーバビリティを充実させることで開発者自身 による運用を実現 SREチーム 開発チーム デプロイ、ロールバック アラート一次対応 アプリケーション起因の問題対応 障害発生時の開発者サポート インフラ起因の問題対応 難易度が高い性能問題等の調査 SREチームは各サービスのオンコールには入らない (大規模なエラー発生時にのみSREの電話も鳴る設定)
47. © GO Inc. 47 新機能の水平展開 プラットフォームに追加した機能はどのサービスでも容易に使える あるチームで生まれた課題によって生まれた機能が他のチームでも使われるため改 善の投資対効果が高い 開発チームの要望で追加された機能の例 ▪ featureブランチから動的に環境を作る機能 ▪ GitHubのリリースノート自動作成 ▪ ローカル開発用シークレットを暗号化してリ ポジトリに保存する機能 ▪ gRPCテスト用Web UI (grpcui)の標準搭載
48. © GO Inc. 48 インフラ構築の効率化 標準化により効率的にインフラ構築が行える ▪ インフラ構築の依頼数 ▪ 毎月平均1,2マイクロサービスの新規構築 ▪ 毎週数回既存サービスの構成変更 負担はあるが対応可能なレベルに収まっている ▪ 最短リードタイム1日程度で新規構築可能 ▪ 既存サービスの構成変更は数十分程度で終わるものが大半 ▪ インフラ構築工数を厳密に計画せずに、オンデマンドの対応で吸収できている状態 インフラ構成と構築手順の標準化によって高い効率で構築作業が行えている
49. © GO Inc. 49 SRE業務の生産性向上 サービス構成が一貫していることで、SREチームがレバレッジ効果 の高い仕事ができる 全マイクロサービスへの変更が必要な大規模なツールの導入を開発者への依頼無しで達成 ▪ 全マイクロサービスのCI/CDをTravis CIからGitHub Actionsに ▪ 全リポジトリのCI設定を書き換え ▪ オブザーバビリティ基盤をNew RelicからGrafanaに ▪ 全サービスのダッシュボードやアラートを書き換え ▪ マイクロサービスへのOpenTelemetryベースのトレースの導入 ▪ 大量のサービスでOpenTelemetryライブラリを使った実装を追加
50. © GO Inc. 50 SRE業務の生産性向上 サービス構成が一貫していることで、SREチームがレバレッジ効果 の高い仕事ができる どのマイクロサービスであっても一般的なオペレーションや構築作業は同じ手順で行える仕 組みになっているため、サービスによらずSRE全員が対応可能となっており、属人性が低い 運用が行えている • 新規マイクロサービスの構築 • RDSやS3といったクラウドリソースの追加 • 障害時のロールバックや再起動 • ログの調査 属人性の軽減
51. © GO Inc. 51 SRE業務の生産性向上 サービス構成が一貫していることで、SREチームがレバレッジ効果 の高い仕事ができる ここまでご紹介したプラットフォーム開発、運用、インフラ構築、開発者サポー トなどは全て5名のSREチームで行っている 少人数チーム
52. © GO Inc. まとめ 52
53. © GO Inc. 53 まとめ プラットフォームエンジニアリングは持続的な標準化の営み プラットフォームエンジニアリングの実践を通して学んだこと プラットフォームのような特定の成果物を作ることではなく、 様々な状況に対応しながら 標準化という手法で 継続的に品質と開発生産性の向上を目指す活動
54. © GO Inc. 54 お知らせ ▪ GO株式会社では、共に働く仲間を募集中 です ▪ 今日お話した開発環境が気になった方はぜひ 一度採用サイトをのぞいてみてください ▪ 技術情報はXにて@goinc_techtalkで 発信しています ▪ 展示エリアでブースも出展しています ▪ エンジニアが参加しておりますので、お気軽 にお立ちよりください 採用サイトはこちら↑ https://goinc.jp/career/
55. © GO Inc. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください