Backlogの成長と共に進化するAWSを活用した Gitホスティングアーキテクチャ 株式会社ヌーラボ サービス開発部 Backlog課 Yuichi Watanabe Copyright Nulab Inc. All Rights Reserved. JAWS FESTA 2023 in Kyushu

イントロダクション Copyright Nulab Inc. All Rights Reserved.

渡邉 祐一 Yuichi Watanabe ・ ・ ・ ・ 福岡在住、2児の父で大学生 BacklogのGitホスティング周りの開発・運用を担当 趣味は小さなツールやライブラリのOSS開発 ・nulab/zxcvbn4j ・sashabaranov/go-openai お気に入りのAWSサービスは、SQSとDynamoDB ※写真は中学生にプログラミングを教える様子 Copyright Nulab Inc. All Rights Reserved. 株式会社ヌーラボ

■ “進んでるね！”で、チームは進む。 みんなで使う簡単、便利な プロジェクト・タスク管理ツール。 タスク管理や Wiki など情報共有に関する豊富な機能がオ ールインワン 直感的に操作が可能なインターフェース SaaS版 / インストール版の2つの形態で提供 ■ ■ 担当者・期限を明確に チームのタスクを、担当者や期限を明確にして課題 を予定通りに完了させましょう。課題の更新は Backlogやメールで受け取れます。 ガントチャートで可視化 プロジェクト計画をガントチャートで可視化します 。メンバーの進捗を把握することで、作業の遅延に いち早く気づけます。 Wikiでドキュメント管理 Backlog Wikiは個人メモ、会議の議事録、作業マニュ アル、仕様書などチームメンバーに向けた情報を文 書で管理します。リンク共有やPDF出力にも対応し ています。 出先からも楽々！モバイルアプリ 無料で使えるBacklogモバイルアプリ（iOS / Android サポート）を利用すれば、外出先でもプロジェクト の進捗を確認したり、課題の追加やコメントを投稿 できます。

コードやコミット履歴をプロジェクト・課題に紐づけて管理できる「Git」機能 プライベートリポジトリを設定 ソースコードをプロジェクトと紐づけて管理できるた め、作業内容を簡単にチームに共有できます。 プルリクエストにコメント ソースコードを指定して、ブランチ間の差分にコメン トをしてペアプログラミングをしているチームメンバ ーにお知らせしましょう。 ソースコードレビュー チームでソースコードレビューができます。ファイル 間の差分は色別で表示されます。誰がどこに変更を加 えたか明確にすることで、どれをマージすべきか即座 に判断できます。 コミット履歴を確認 ブランチごとにコミット履歴を確認できます。ファイ ルブラウザから履歴を閲覧するとファイルに関連する 履歴のみを閲覧できます。

アジェンダ 初期のアーキテクチャと課題 可用性を高めるアーキテクチャへの刷新 運用作業の効率化 1 2 3 コンピューターリソースとコストの最適化 4 まとめ 5

初期のアーキテクチャと課題 Copyright Nulab Inc. All Rights Reserved.

初期のアーキテクチャと課題 AWS Cloud [EC2] GIT [EBS] Ripository 本体 WEB 本体 API 初期のアーキテクチャ ・Backlog本体からGitのコア機能を切り出したアプリをEC2（通称Gitサーバー）で 稼働。（ストレージを本体に持たせると本体がスケールできなくなるため） ・本体はGitサーバーにRPCで接続してリポジトリのデータを読み書き。 ・複数のGitサーバーが一定のグループ毎に割り振られる。 ・グループに応じて適切なGitサーバーへ接続される。 ・Gitサーバーは複数のEBSをマウントしてGitリポジトリを保持。 ・Gitリポジトリは一定のグループに分けて特定のEBSに保存。 １サーバー・マルチプロセス Gitサーバーではマルチプロセスで複数のアプリが起動 ・Git HTTPSの認証、Git特有のHTTPプロトコルの解釈、リポジトリのIOを行うアプリ。 ・Git SSHの認証、SSH接続、リポジトリのIOを行うアプリ。 ・Backlog本体からのRPC接続、リポジトリのIOを行うアプリ。 ・書き込み時の重たい処理を非同期で行うアプリ。 WORKE R HTTPS SSH RPC ※ コンポーネント間のLBなどは省略

初期のアーキテクチャと課題 EC2の再起動によるダウンタイム EC2のセキュリティパッチを適用する際に伴う、EC2再起動でGit機能のダウン タイムが発生していた。 EBSの冗長化 EBSスナップショットは定期的に保持していたが、EBSそのものを冗長化して いなかった。 Backlogの成長に伴い、ダウンタイムを削減して可用性を向上させたい。 AWS Cloud [EC2] GIT [EBS] Ripository 本体 WEB 本体 API Logs... Down time... Replication... 当初の運用上の課題 ※ コンポーネント間のLBなどは省略

可用性を高める アーキテクチャへの刷新 Copyright Nulab Inc. All Rights Reserved.

可用性を高めるアーキテクチャへの刷新 1. Amazon EFS ・複数のAZで冗長化されており、高い耐 久性を持つ。 ・複数のEC2からマウント可能。 ・リポジトリの状態によってCPU、ディ スクIOが跳ねやすく、EBSの10倍程度パ フォーマンスが損なわれる。 3. Amazon EBS ・パフォーマンスはEBS一択。 ・複数のEC2からマウント不可。 ・ネットワーク越しに異なるEBSへ複製 する仕組みが必要。 2. Amazon S3 ・s3fs(FUSE)等のファイルシステムとし てマウントさせるツールが必要。 ・読み書きするファイルが増えると線形 に通信コストが増えて、パフォーマンス が損なわれる。 可用性を高めるためのストレージの見直し

可用性を高めるアーキテクチャへの刷新 1. 同期レプリケーション（強い整合性） ・複数のストレージに同時に書き込む。 ・データの整合性が高い。データロスのリスクが非常に低い。 ・レイテンシーが増加して、書き込みのパフォーマンスが低下 する可能性がある。 ・3PC等の分散アルゴリズムを用いてネットワーク越しのトラン ザクションが必要。 2. 非同期レプリケーション（結果整合） ・プライマリのストレージに書き込まれると、その情報をキュ ーに追加する。 ・セカンダリに実際に書き込まれる前に、書き込み操作が完了 したことを通知する。 ・データが同期するまでにタイムラグがあるが、レイテンシー の影響を受けにくい。 Something [EC2] GIT [EBS] Ripository [EC2] GIT [EBS] Ripository ① ② ③ ④ Something [EC2] GIT [EBS] Ripository [EC2] GIT [EBS] Ripository ① ② ③ ④ レプリケーション方式の検討 ⑤

可用性を高めるアーキテクチャへの刷新 AWS Cloud [EC2] GIT [EBS] Ripository 本体 WEB 本体 API アイコンは新しく追加されたコンポーネント。 ※ コンポーネント間のLBなどは省略 新しいアーキテクチャの概観（Before & After） AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica）

可用性を高めるアーキテクチャへの刷新 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） 認証認可の部分やGit特有の通信プロトコルの実装など、Gitリポジト リの読み書きの手前の部分（ストレージに依存しない部分）は、 ECS Fargateでコンテナ化してスケールさせやすくした。 ストレージに依存しないフロントエンドはECS Fargateへ WORKE R HTTPS SSH RPC

可用性を高めるアーキテクチャへの刷新 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） ・図の後段に配備されるGitサーバーのみストレージに依存する。 ・フロントエンドからRPCを受けGitリポジトリへ読み書きを行う。 ・アクティブ・アクティブなプライマリ・レプリカ構成 ・レプリカはプライマリを正とした複製。 ・書き込み系のRPCは全てプライマリで受ける。 ・読み取り系のRPCはプライマリかレプリカのどちらかで受ける。 ストレージに依存するバックエンドはプライマリ・レプリカ構成

可用性を高めるアーキテクチャへの刷新 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） ECS Fargateで稼働するGit Proxyはフロントからの全てのRPC（gRPC）を 適切なバックエンドへ中継し、書き込み時はレプリケーションログを発行す る。 処理の流れ： レプリケーションの中核となる動的なプロキシ RPCの属性の読み取り 書き込み or 読み取りの判定 プライマリへ中継 S3にレプリケーションログを送 信 SQSにメッセージを送信 プライマリへ中継 レプリケーション中か判定（S3 のログを検索） プライマリ or レプリカ へ中継 書き込み 読み取り 完了 未完了

可用性を高めるアーキテクチャへの刷新 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） レプリケーションログは、Git ProxyやReplication Workerから参照される 重要なデータ。常に最新のレプリケーションログにアクセスできる必要が ある。 S3を選択した理由： ・SQS自体はIDを指定したメッセージの参照をサポートしていない。 ・ログの実態はSQSの外に保持する必要がある。 ・S3がStrong Consistencyをサポート。 ・S3は常に最新のデータを返すためログの整合性が保たれる。 強い一貫性を持つAmazon S3に保持するレプリケーションログ

可用性を高めるアーキテクチャへの刷新 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） ・レプリケーションログはリポジトリ単位で発行。 ・ログの種類は書き込み属性に応じて複数のイベントに分類。 ・レプリケーションの実行順序を守る必要がある。（以下、例） 1. リポジトリの作成 2. リポジトリへの書き込み 3. リポジトリのリネーム 4. リポジトリの削除 ・SQSのFIFO + メッセージグループ化機能で順序を保証する。 ・エンキューするメッセージにグループIDを付与すると、同一グループID のメッセージの配信順序が保証される。 Amazon SQSのFIFO・グループ化を用いた配信順序の保証

可用性を高めるアーキテクチャへの刷新 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） ・Replication WorkerはSQSをポーリングする。 ・Replication WorkerはECS Fargateで冗長化されており、単一のECSタス クで複数のメッセージを同時に処理する。 ・取得したメッセージに含まれるキーを元に、S3上のレプリケーションロ グの実態を取得する。 ・レプリケーションログの内容から、対象のGitリポジトリとレプリケーシ ョンの種別を特定して、レプリカのGitサーバーが提供するリポジトリのレ プリケーション用の適切なRPCを実行する。 ・レプリケーションが成功すると、S3のレプリケーションログとSQSのメ ッセージを削除する。レプリケーションが失敗した場合はSQSの可視性タ イムアウトを更新してリトライする。 ワーカーによるレプリケーションの制御

運用作業の効率化 Copyright Nulab Inc. All Rights Reserved.

運用作業の効率化 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） プライマリ・レプリカ構成の非同期レプリケーション方式になり、カーネル アップデートに伴う作業がオンラインかつ自動でできるようになった。 EC2のセキュリティパッチ適用に伴う作業のオンライン化と自動化 Jenkinsによるオンラインアップデートの流れ： 1. Git ProxyのECSタスクが持つクラスタ設定からレプリカを抜いてリクエ ストをプライマリのみに中継。 2. Replication WorkerのECSタスクを0にしてレプリケーションを停止。 3. レプリカのEC2にセキュリティパッチを当てて再起動。 4. Replication WorkerのECSタスクを起動してレプリケーションを再開。 5. Git ProxyのECSタスクが持つクラスタ設定にレプリカを追加。 6. プライマリとレプリカのEC2をスイッチする。 7. 再度1.から5.の作業をスイッチしたレプリカに実施する。

運用作業の効率化 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） プライマリ・レプリカ構成の非同期レプリケーション方式になり、カーネル アップデートに伴う作業がオンラインかつ自動でできるようになった。 EC2のセキュリティパッチ適用に伴う作業のオンライン化と自動化 Jenkinsによるオンラインアップデートの流れ： 1. Git ProxyのECSタスクが持つクラスタ設定からレプリカを抜いてリク エストをプライマリのみに中継。 2. Replication WorkerのECSタスクを0にしてレプリケーションを停止。 3. レプリカのEC2にセキュリティパッチを当てて再起動。 4. Replication WorkerのECSタスクを起動してレプリケーションを再開。 5. Git ProxyのECSタスクが持つクラスタ設定にレプリカを追加。 6. プライマリとレプリカのEC2をスイッチする。 7. 再度1.から5.の作業をスイッチしたレプリカに実施する。

運用作業の効率化 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） プライマリ・レプリカ構成の非同期レプリケーション方式になり、カーネル アップデートに伴う作業がオンラインかつ自動でできるようになった。 EC2のセキュリティパッチ適用に伴う作業のオンライン化と自動化 Jenkinsによるオンラインアップデートの流れ： 1. Git ProxyのECSタスクが持つクラスタ設定からレプリカを抜いてリクエ ストをプライマリのみに中継。 2. Replication WorkerのECSタスクを0にしてレプリケーションを停止。 3. レプリカのEC2にセキュリティパッチを当てて再起動。 4. Replication WorkerのECSタスクを起動してレプリケーションを再開。 5. Git ProxyのECSタスクが持つクラスタ設定にレプリカを追加。 6. プライマリとレプリカのEC2をスイッチする。 7. 再度1.から5.の作業をスイッチしたレプリカに実施する。

運用作業の効率化 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） プライマリ・レプリカ構成の非同期レプリケーション方式になり、カーネル アップデートに伴う作業がオンラインかつ自動でできるようになった。 EC2のセキュリティパッチ適用に伴う作業のオンライン化と自動化 Jenkinsによるオンラインアップデートの流れ： 1. Git ProxyのECSタスクが持つクラスタ設定からレプリカを抜いてリクエ ストをプライマリのみに中継。 2. Replication WorkerのECSタスクを0にしてレプリケーションを停止。 3. レプリカのEC2にセキュリティパッチを当てて再起動。 4. Replication WorkerのECSタスクを起動してレプリケーションを再開。 5. Git ProxyのECSタスクが持つクラスタ設定にレプリカを追加。 6. プライマリとレプリカのEC2をスイッチする。 7. 再度1.から5.の作業をスイッチしたレプリカに実施する。 Applay Patch & Reboot

運用作業の効率化 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） プライマリ・レプリカ構成の非同期レプリケーション方式になり、カーネル アップデートに伴う作業がオンラインかつ自動でできるようになった。 EC2のセキュリティパッチ適用に伴う作業のオンライン化と自動化 Jenkinsによるオンラインアップデートの流れ： 1. Git ProxyのECSタスクが持つクラスタ設定からレプリカを抜いてリクエ ストをプライマリのみに中継。 2. Replication WorkerのECSタスクを0にしてレプリケーションを停止。 3. レプリカのEC2にセキュリティパッチを当てて再起動。 4. Replication WorkerのECSタスクを起動してレプリケーションを再開。 5. Git ProxyのECSタスクが持つクラスタ設定にレプリカを追加。 6. プライマリとレプリカのEC2をスイッチする。 7. 再度1.から5.の作業をスイッチしたレプリカに実施する。

運用作業の効率化 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） プライマリ・レプリカ構成の非同期レプリケーション方式になり、カーネル アップデートに伴う作業がオンラインかつ自動でできるようになった。 EC2のセキュリティパッチ適用に伴う作業のオンライン化と自動化 Jenkinsによるオンラインアップデートの流れ： 1. Git ProxyのECSタスクが持つクラスタ設定からレプリカを抜いてリクエ ストをプライマリのみに中継。 2. Replication WorkerのECSタスクを0にしてレプリケーションを停止。 3. レプリカのEC2にセキュリティパッチを当てて再起動。 4. Replication WorkerのECSタスクを起動してレプリケーションを再開。 5. Git ProxyのECSタスクが持つクラスタ設定にレプリカを追加。 6. プライマリとレプリカのEC2をスイッチする。 7. 再度1.から5.の作業をスイッチしたレプリカに実施する。

運用作業の効率化 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） プライマリ・レプリカ構成の非同期レプリケーション方式になり、カーネル アップデートに伴う作業がオンラインかつ自動でできるようになった。 EC2のセキュリティパッチ適用に伴う作業のオンライン化と自動化 Jenkinsによるオンラインアップデートの流れ： 1. Git ProxyのECSタスクが持つクラスタ設定からレプリカを抜いてリクエ ストをプライマリのみに中継。 2. Replication WorkerのECSタスクを0にしてレプリケーションを停止。 3. レプリカのEC2にセキュリティパッチを当てて再起動。 4. Replication WorkerのECSタスクを起動してレプリケーションを再開。 5. Git ProxyのECSタスクが持つクラスタ設定にレプリカを追加。 6. プライマリとレプリカのEC2をスイッチする。 7. 再度1.から5.の作業をスイッチしたレプリカに実施する。 Switch Over

運用作業の効率化 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） プライマリ・レプリカ構成の非同期レプリケーション方式になり、カーネル アップデートに伴う作業がオンラインかつ自動でできるようになった。 EC2のセキュリティパッチ適用に伴う作業のオンライン化と自動化 Jenkinsによるオンラインアップデートの流れ： 1. Git ProxyのECSタスクが持つクラスタ設定からレプリカを抜いてリクエ ストをプライマリのみに中継。 2. Replication WorkerのECSタスクを0にしてレプリケーションを停止。 3. レプリカのEC2にセキュリティパッチを当てて再起動。 4. Replication WorkerのECSタスクを起動してレプリケーションを再開。 5. Git ProxyのECSタスクが持つクラスタ設定にレプリカを追加。 6. プライマリとレプリカのEC2をスイッチする。 7. 再度1.から5.の作業をスイッチしたレプリカに実施する。

コンピューターリソースと コストの最適化 Copyright Nulab Inc. All Rights Reserved.

パフォーマンスとコストの最適化 コンピューターリソースとコストの最適化 AWS Cloud 本体 WEB 本体 API [ECS] Git PROXY [ECS] Git HTTPS [ECS] Replication Worker [ECS] Git SSH [SQS] [S3] [EC2] GIT [EBS] Ripository （Primary） [EC2] GIT [EBS] Ripository （Replica） [ECS] GC Worker EventBridge Scheduler [SQS] ・処理コストの高いGit GCが頻繁に発生してEC2のコンピューター リソースを大幅に消費する問題があった。 ・Git GCの実行をフックしていったんGC対象のリポジトリ情報を SQSに貯めて、アクセスの少ない深夜帯に処理するようにした。 ・この日時バッチにAWS Lamdaを使用するのは、Git GCの実行時間 が長いので断念した。 ・処理時間に対応するために、EventBridge SchedulerでECS Fargateのタスクを日時で定期実行するようにした。 EventBridge SchedulerとECS Fargateを用いたGit GCのバッチ処理

コンピューターリソースとコストの最適化 X86からARM64に移行 リージョン: ap-northeast-1 vCPU単位（1時間） GB単位（1時間） X86 0.05056USD 0.00553USD ARM 0.04045USD 0.00442USD ※ 2023/10/6時点 -25% Compute Savings Plansの適用 リージョン: ap-northeast-1, CPUアーキテクチャ: ARM vCPU単位（1時間） GB単位（1時間） オンデマンド 0.04045USD 0.00442USD Savings Plans 0.03185USD 0.00348USD ※ 2023/10/6時点 -27% ECS Fargateのコスト最適化

まとめ Copyright Nulab Inc. All Rights Reserved.

まとめ ・ストレージを持たないコンポーネントは、ECS Fargateを使ってサーバーレスな運用ができるようになった。 ・ストレージを持つコンポーネントはEC2+EBSのまま、アクティブ・アクティブなプライマリ・レプリカ構成で冗長化した。 ・レプリケーションで重要なレプリケーションログはStrong ConsistencyなS3に保持して整合性を担保した。 ・SQSのFIFO・グループ化機能を用いて配信順序を保証した。 ・アーキテクチャを刷新したことでダウンタイム無しでセキュリティパッチを適用できるようになった。 ・EventBridge SchedulerとECS Fargateを活用して重たいGit GCのバッチ処理を深夜帯に導入した。 ・ECS FargateをX86からARM64へ移行し、Savings Plansを導入することで、大幅なコスト削減が実現された。 BacklogのGitホスティングはAWSのマネージドサービスを活用して可用性の向上と運用作業を効率化した。