Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

GO Inc. dev

June 28, 2024
Tweet

More Decks by GO Inc. dev

Other Decks in Technology

Transcript

  1. © GO Inc. 2 自己紹介 GO株式会社 技術戦略部 部長 技術戦略部SREグループ グループマネージャ

    水戸 祐介 2018年にGO株式会社の前身となるJapanTaxi株式会社に入社し、以来SREとして 継続してインフラ基盤開発や運用に携わる @y_310
  2. © GO Inc. 9 『GO』の裏側 ▪ 100以上のマイクロサービスで構成 ▪ 開発者100人以上、開発チーム10以上 タクシー事業者向け

    
 車載系
 基幹系
 分析系
 法人向け
 消費者向け
 ユーザーアプリ 
 (iOS)
 ユーザーアプリ (Android)
 配車系APIサー バ群
 管理画面
 ジオ・AI系サー バ群
 決済系
 サーバ群
 GO CALL
 GO CALL Pro 
 支払請求系 
 サーバ群
 乗務員向け アプリ
 後部座席
 アプリ
 Redash
 Looker
 GO BUSINESS 
 社内向け管理画面 系サーバ群 
 乗務員
 ポータル

  3. © GO Inc. 11 Kenos - クラスタ 大量のマイクロサービスを動かす 基盤となるKubernetesクラスタ マイクロサービスを構成する基本

    コンポーネント ▪ APIサーバ ▪ 非同期ジョブワーカー ▪ 定期実行バッチ これらを柔軟に組み合わせてデプ ロイできる仕組みを提供 マイクロサービス APIサーバ 非同期ジョブ ワーカー 定期実行バッチ マイクロサービス APIサーバ APIサーバ マイクロサービス 非同期ジョブ ワーカー 定期実行バッチ 非同期ジョブ ワーカー 定期実行バッチ 様々なコンポーネントの組み合わせでマイクロ サービスを定義
  4. © GO Inc. 12 Kenos - CLIツール kns 開発者が簡単にKubernetesクラスタにアクセスしてオペレーションできるよう にするためのCLIツール

    マイクロサービス環境で使うことを前提にすることでシンプルな使用体験を提供して いる • 開発環境のコンテナのログを表示 • 本番環境のコンテナにログイン • 開発環境でkubectl実行環境を起動 kns dev logs kns prod connect kns dev cli Pod名指定やコンテキスト切り替えをせずにログが表示できる 環境名を変えるだけでコンテキストが切り替わり安全にコンテナに ログインできる ローカルでkubectl等がインストールされたコンテナが起動しラップさ れていないコマンドを直接実行することもできる
  5. © GO Inc. 13 Kenos - マイクロサービステンプレート マイクロサービスをすぐに開発開始できるリポジトリテンプ レート 開発からリリースまでに必要な共通機能を予め用意しておくことで

    ビジネスロジックに集中して開発ができる ▪ 基本設計 ▪ gRPC/RESTサーバフレームワーク ▪ Clean Architectureベースのディレクトリ設計とサンプルコード ▪ 社内標準ライブラリ (ロガー、暗号化など) ▪ 開発ツール ▪ makeによるビルド、テスト、実行コマンド ▪ RDB等を開発環境で起動するための docker-compose.yml ▪ flywayを使用したDBマイグレーション用のコマンド ▪ デプロイ設定 ▪ デプロイ用Dockerfile ▪ CI/CD関連の設定ファイル ▪ Kenosクラスタにデプロイするリソースの設定ファイル
  6. © GO Inc. 14 Kenos - オブザーバビリティ基盤 Grafanaによるオブザーバビリ ティ基盤 デプロイしたマイクロサービスのメト

    リクス、ログ、トレースが自動的に収 集されGrafana上で参照できる ダッシュボード、アラート一式が予め 作成されているためリリース当初から 十分にオブザーバビリティが確保され た状態で安定した運用が行える サービスによらず同じ定義でダッシュ ボードが作られているためどのサービ スを見てもすぐに状況が把握できる
  7. © GO Inc. 15 Kenos - ワークフロー基盤 Airflowによるワークフロー基盤 多段階の複雑なバッチ処理を実行するた めの仕組み

    Kenos (k8s)とAirflowを連携させること で、デプロイ設定ファイルに簡単なジョ ブ定義を記述し、ワークフロー定義 (DAG)から呼び出すだけでワークフロー を実行できる基盤 決済データの月次締め処理などで利用さ れている
  8. © GO Inc. 27 GOではSREチームがプラットフォームを開発しています ▪ そもそもプラットフォームの開発を始めた2019年頃はまだプラットフォーム エンジニアリングという言葉も無かった ▪ 業務特性の面から当面SREとプラットフォーム開発は分離しない予定

    SRE Platform 日々のインフラ監視 インフラ構築 定常業務の自動化、など プラットフォーム開発 標準化 ツール開発、など Devよりの業務 Opsよりの業務 分離するとDev vs Opsな Before DevOps時代的構造に なってしまうリスク Opsの実践による課題発見がDevの業務の元に なることも多く簡単に線引きできない側面も
  9. © GO Inc. 30 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪

    サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
  10. © GO Inc. 開発者 ビジネスロジックの実装 SRE 非機能要件全般の標準化とツールの開発、 インフラの構築 31 責任境界を高いラインに設定

    インフラだけでなくアプリケーションまで踏み 込んで標準化することで品質と生産性を担保 例えば リポジトリテンプレートを提供することでサーバとしての基本動作を担保し、 運用品質を上げている
  11. © GO Inc. 32 責任境界を高いラインに設定 アプリケーションの非機能要件までを責任範囲とした理由 標準化可能な領域を全て標準化しようとした結果 その名の通り、サービス固有のロジックなので標準化はできない サービスに依存しないロジックなので標準化しやすい インフラの上でどんなアプリケーションが動いている

    かはあまり関係がないので標準化しやすい 例: 注文処理、決済処理、ユーザ情報の管理など 例: デプロイ、ロギング、設定値の管理、サーバの起動終了、通信プロトコルなど 例: ロードバランサー、k8sのDeployment、DBの基本設定、S3などのクラウドリソースのパラメータ
  12. © GO Inc. 33 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪

    サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
  13. © GO Inc. 37 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪

    サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
  14. © GO Inc. 38 サービスのアーキテクチャレビューを行う 標準の維持が一番の目的 ▪ 標準を全て言語化、仕組み化するのは難しい ▪ レビューを通して、同じ課題は同じ方法で解決するように設計を修

    正し、パターンが発散していくのを抑止している 開発チームのアーキテクチャ設計をSREが必ずレビュー 例えば MemcachedやRDBが悪いわけではなく、同じ課題を解決するのに違う方法を使わないことを重視 標準の選択肢で解決できない課題に対して別の技術を使うことは厭わない
  15. © GO Inc. 40 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪

    サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
  16. © GO Inc. 41 完璧なプラットフォームを目指さない 実際に発生している課題を解決する GOではプラットフォームの長期ロードマップは 持たず、常に次の半年に作るものだけを決めてプ ラットフォームを改善してきた 次の半年の開発目標設定

    半年で開発してリリース 最新の課題を収集 作っているのはあくまで社内プラットフォーム 世の中で一般的にニーズがある機能でも社内に ニーズが無いなら作る意味がない 場当たり的な拡張ではなく、疎結合なコンポーネントの積み 上げによって長期プラン無しでも拡張性を維持している
  17. © GO Inc. 42 プラットフォームエンジニアリング実践の鍵 ▪ 責任境界を高いラインに設定 ▪ インフラ構築作業をSREがすべて巻き取る ▪

    サービスのアーキテクチャレビューを行う ▪ 完璧なプラットフォームを目指さない ▪ 開発者の課題解決が最優先
  18. © GO Inc. 43 開発者の課題解決が最優先 プラットフォームの既存機能やポリシーでは対応できない要望が 来ても開発者の課題解決を最優先に動く 要望の根幹にある解決し たい課題を理解する 負債になりづらい暫定案

    を考える 開発者の課題を解決する 要望そのものではなく本質的に何 が解決されればよいのかを考える 単なるその場しのぎではなく、後 からやり直しやすい方法を探す 開発者の課題はスケジュール内に 解決し、プラットフォームの課題 は後から解決する 開発者の行き止まりを作らない事が重要 一方でプラットフォームの将来性を犠牲にする安易な例外対応は避ける
  19. © GO Inc. 46 開発者によるサービス運用 自動化とオブザーバビリティを充実させることで開発者自身 による運用を実現 SREチーム 開発チーム デプロイ、ロールバック

    アラート一次対応 アプリケーション起因の問題対応 障害発生時の開発者サポート インフラ起因の問題対応 難易度が高い性能問題等の調査 SREチームは各サービスのオンコールには入らない (大規模なエラー発生時にのみSREの電話も鳴る設定)
  20. © GO Inc. 47 新機能の水平展開 プラットフォームに追加した機能はどのサービスでも容易に使える あるチームで生まれた課題によって生まれた機能が他のチームでも使われるため改 善の投資対効果が高い 開発チームの要望で追加された機能の例 ▪

    featureブランチから動的に環境を作る機能 ▪ GitHubのリリースノート自動作成 ▪ ローカル開発用シークレットを暗号化してリ ポジトリに保存する機能 ▪ gRPCテスト用Web UI (grpcui)の標準搭載
  21. © GO Inc. 48 インフラ構築の効率化 標準化により効率的にインフラ構築が行える ▪ インフラ構築の依頼数 ▪ 毎月平均1,2マイクロサービスの新規構築

    ▪ 毎週数回既存サービスの構成変更 負担はあるが対応可能なレベルに収まっている ▪ 最短リードタイム1日程度で新規構築可能 ▪ 既存サービスの構成変更は数十分程度で終わるものが大半 ▪ インフラ構築工数を厳密に計画せずに、オンデマンドの対応で吸収できている状態 インフラ構成と構築手順の標準化によって高い効率で構築作業が行えている
  22. © GO Inc. 49 SRE業務の生産性向上 サービス構成が一貫していることで、SREチームがレバレッジ効果 の高い仕事ができる 全マイクロサービスへの変更が必要な大規模なツールの導入を開発者への依頼無しで達成 ▪ 全マイクロサービスのCI/CDをTravis

    CIからGitHub Actionsに ▪ 全リポジトリのCI設定を書き換え ▪ オブザーバビリティ基盤をNew RelicからGrafanaに ▪ 全サービスのダッシュボードやアラートを書き換え ▪ マイクロサービスへのOpenTelemetryベースのトレースの導入 ▪ 大量のサービスでOpenTelemetryライブラリを使った実装を追加
  23. © GO Inc. 54 お知らせ ▪ GO株式会社では、共に働く仲間を募集中 です ▪ 今日お話した開発環境が気になった方はぜひ

    一度採用サイトをのぞいてみてください ▪ 技術情報はXにて@goinc_techtalkで 発信しています ▪ 展示エリアでブースも出展しています ▪ エンジニアが参加しておりますので、お気軽 にお立ちよりください 採用サイトはこちら↑ https://goinc.jp/career/