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

by GO Inc. dev

Slide 1

Slide 1 text

タクシーアプリ『GO』におけるプラットフォームエンジニアリングの実践 2024.06.28 水戸祐介 GO株式会社

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© GO Inc. 9 『GO』の裏側 ▪ 100以上のマイクロサービスで構成 ▪ 開発者100人以上、開発チーム10以上タクシー事業者向け   車載系  基幹系  分析系  法人向け  消費者向け  ユーザーアプリ   (iOS)  ユーザーアプリ (Android)  配車系APIサーバ群  管理画面  ジオ・AI系サーバ群  決済系  サーバ群  GO CALL  GO CALL Pro   支払請求系   サーバ群  乗務員向けアプリ  後部座席  アプリ  Redash  Looker  GO BUSINESS   社内向け管理画面系サーバ群   乗務員  ポータル 

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© GO Inc. 11 Kenos - クラスタ大量のマイクロサービスを動かす基盤となるKubernetesクラスタマイクロサービスを構成する基本コンポーネント ▪ APIサーバ ▪ 非同期ジョブワーカー ▪ 定期実行バッチこれらを柔軟に組み合わせてデプロイできる仕組みを提供マイクロサービス APIサーバ非同期ジョブワーカー定期実行バッチマイクロサービス APIサーバ APIサーバマイクロサービス非同期ジョブワーカー定期実行バッチ非同期ジョブワーカー定期実行バッチ様々なコンポーネントの組み合わせでマイクロサービスを定義

Slide 12

Slide 12 text

© GO Inc. 12 Kenos - CLIツール kns 開発者が簡単にKubernetesクラスタにアクセスしてオペレーションできるようにするためのCLIツールマイクロサービス環境で使うことを前提にすることでシンプルな使用体験を提供している ● 開発環境のコンテナのログを表示 ● 本番環境のコンテナにログイン ● 開発環境でkubectl実行環境を起動 kns dev logs kns prod connect kns dev cli Pod名指定やコンテキスト切り替えをせずにログが表示できる環境名を変えるだけでコンテキストが切り替わり安全にコンテナにログインできるローカルでkubectl等がインストールされたコンテナが起動しラップされていないコマンドを直接実行することもできる

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

© GO Inc. 14 Kenos - オブザーバビリティ基盤 Grafanaによるオブザーバビリティ基盤デプロイしたマイクロサービスのメトリクス、ログ、トレースが自動的に収集されGrafana上で参照できるダッシュボード、アラート一式が予め作成されているためリリース当初から十分にオブザーバビリティが確保された状態で安定した運用が行えるサービスによらず同じ定義でダッシュボードが作られているためどのサービスを見てもすぐに状況が把握できる

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© GO Inc. 車輪の再発明による非効率化 AWS、GCP、Azureと3クラウドに渡って様々な方式でサービスが稼働しており、それぞれでデプロイやオートスケール、監視、ロギングなどを個別実装していた不十分な運用実際にはリソース不足で作り切れないチームも多く、運用コストが高いまま運用が続けられていることもあった 22 技術スタックの乱立デプロイの属人化アラートが不足し障害に気付かないログが柔軟に検索できず問題調査に時間がかかるなど

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© GO Inc. 27 GOではSREチームがプラットフォームを開発しています ▪ そもそもプラットフォームの開発を始めた2019年頃はまだプラットフォームエンジニアリングという言葉も無かった ▪ 業務特性の面から当面SREとプラットフォーム開発は分離しない予定 SRE Platform 日々のインフラ監視インフラ構築定常業務の自動化、などプラットフォーム開発標準化ツール開発、など Devよりの業務 Opsよりの業務分離するとDev vs Opsな Before DevOps時代的構造になってしまうリスク Opsの実践による課題発見がDevの業務の元になることも多く簡単に線引きできない側面も

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© GO Inc. 32 責任境界を高いラインに設定アプリケーションの非機能要件までを責任範囲とした理由標準化可能な領域を全て標準化しようとした結果その名の通り、サービス固有のロジックなので標準化はできないサービスに依存しないロジックなので標準化しやすいインフラの上でどんなアプリケーションが動いているかはあまり関係がないので標準化しやすい例: 注文処理、決済処理、ユーザ情報の管理など例: デプロイ、ロギング、設定値の管理、サーバの起動終了、通信プロトコルなど例: ロードバランサー、k8sのDeployment、DBの基本設定、S3などのクラウドリソースのパラメータ

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© GO Inc. 38 サービスのアーキテクチャレビューを行う標準の維持が一番の目的 ▪ 標準を全て言語化、仕組み化するのは難しい ▪ レビューを通して、同じ課題は同じ方法で解決するように設計を修正し、パターンが発散していくのを抑止している開発チームのアーキテクチャ設計をSREが必ずレビュー例えば MemcachedやRDBが悪いわけではなく、同じ課題を解決するのに違う方法を使わないことを重視標準の選択肢で解決できない課題に対して別の技術を使うことは厭わない

Slide 39

Slide 39 text

© GO Inc. 39 サービスのアーキテクチャレビューを行う標準に揃えることにこだわる理由どんなものでも作った後に問題は起き、解決していく必要がある持続的に品質を維持するには、発生する問題のパターンを収束させ問題解決のコストを最小化する必要がある問題の種類が発散し個別解決が必要になる一箇所で問題を解決すれば他の場所にも水平展開できる (問題がまだ起きていない場所では未然に解決もできる) 同じ課題を違う方法で実装すると同じ課題を同じ方法で実装すると

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© GO Inc. 41 完璧なプラットフォームを目指さない実際に発生している課題を解決する GOではプラットフォームの長期ロードマップは持たず、常に次の半年に作るものだけを決めてプラットフォームを改善してきた次の半年の開発目標設定半年で開発してリリース最新の課題を収集作っているのはあくまで社内プラットフォーム世の中で一般的にニーズがある機能でも社内にニーズが無いなら作る意味がない場当たり的な拡張ではなく、疎結合なコンポーネントの積み上げによって長期プラン無しでも拡張性を維持している

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© GO Inc. 43 開発者の課題解決が最優先プラットフォームの既存機能やポリシーでは対応できない要望が来ても開発者の課題解決を最優先に動く要望の根幹にある解決したい課題を理解する負債になりづらい暫定案を考える開発者の課題を解決する要望そのものではなく本質的に何が解決されればよいのかを考える単なるその場しのぎではなく、後からやり直しやすい方法を探す開発者の課題はスケジュール内に解決し、プラットフォームの課題は後から解決する開発者の行き止まりを作らない事が重要一方でプラットフォームの将来性を犠牲にする安易な例外対応は避ける

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

© GO Inc. 47 新機能の水平展開プラットフォームに追加した機能はどのサービスでも容易に使えるあるチームで生まれた課題によって生まれた機能が他のチームでも使われるため改善の投資対効果が高い開発チームの要望で追加された機能の例 ▪ featureブランチから動的に環境を作る機能 ▪ GitHubのリリースノート自動作成 ▪ ローカル開発用シークレットを暗号化してリポジトリに保存する機能 ▪ gRPCテスト用Web UI (grpcui)の標準搭載

Slide 48

Slide 48 text

© GO Inc. 48 インフラ構築の効率化標準化により効率的にインフラ構築が行える ▪ インフラ構築の依頼数 ▪ 毎月平均1,2マイクロサービスの新規構築 ▪ 毎週数回既存サービスの構成変更負担はあるが対応可能なレベルに収まっている ▪ 最短リードタイム1日程度で新規構築可能 ▪ 既存サービスの構成変更は数十分程度で終わるものが大半 ▪ インフラ構築工数を厳密に計画せずに、オンデマンドの対応で吸収できている状態インフラ構成と構築手順の標準化によって高い効率で構築作業が行えている

Slide 49

Slide 49 text

© GO Inc. 49 SRE業務の生産性向上サービス構成が一貫していることで、SREチームがレバレッジ効果の高い仕事ができる全マイクロサービスへの変更が必要な大規模なツールの導入を開発者への依頼無しで達成 ▪ 全マイクロサービスのCI/CDをTravis CIからGitHub Actionsに ▪ 全リポジトリのCI設定を書き換え ▪ オブザーバビリティ基盤をNew RelicからGrafanaに ▪ 全サービスのダッシュボードやアラートを書き換え ▪ マイクロサービスへのOpenTelemetryベースのトレースの導入 ▪ 大量のサービスでOpenTelemetryライブラリを使った実装を追加

Slide 50

Slide 50 text

© GO Inc. 50 SRE業務の生産性向上サービス構成が一貫していることで、SREチームがレバレッジ効果の高い仕事ができるどのマイクロサービスであっても一般的なオペレーションや構築作業は同じ手順で行える仕組みになっているため、サービスによらずSRE全員が対応可能となっており、属人性が低い運用が行えている ● 新規マイクロサービスの構築 ● RDSやS3といったクラウドリソースの追加 ● 障害時のロールバックや再起動 ● ログの調査属人性の軽減

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© GO Inc. 54 お知らせ ▪ GO株式会社では、共に働く仲間を募集中です ▪ 今日お話した開発環境が気になった方はぜひ一度採用サイトをのぞいてみてください ▪ 技術情報はXにて@goinc_techtalkで発信しています ▪ 展示エリアでブースも出展しています ▪ エンジニアが参加しておりますので、お気軽にお立ちよりください採用サイトはこちら↑ https://goinc.jp/career/

Slide 55

Slide 55 text