minimo 事業部における開発基盤の整備（ChatOps + GItHub Actions）【MIXI TECH CONFERENCE 2023】

MIXI TECH CONFERENCE 2023
にてお話した洗川＆鈴木の資料です。

動画：https://youtu.be/irO5Yk1JvYE

https://techcon.mixi.co.jp/2023/d3-2

1. minimo 事業部における開発基盤の整 備（ChatOps + GitHub Actions） MIXI TECH CONFERENCE 2023 DAY3 D3-2 (C)MIXI
2. 概要 • minimoについて • ChatOps • GitHub Actions (C)MIXI
3. minimoについて (C)MIXI
4. minimoについて • 1月で9周年を迎えたサービス • 美容師やネイリスト、アイデザイナー等を予 約・検索できるアプリ • サロンスタッフと直接やり取りができる • 直近だと、パーソナルカラー診断のコンテン ツを追加した (C)MIXI https://minimodel.jp/about
5. ChatOps (C)MIXI
6. 自己紹介
7. 自己紹介 • 洗川 雄輝 • 株式会社MIXI所属 ◦ minimo事業部には2年半ほど前にJoin ◦ コンテナ移行、Go移行などを担当 • よく触るのはAWS、Unity • OSS ◦ https://github.com/yukiarrr/ecsk ◦ ECSのタスク操作をインタラクティブにできるツール ◦ 今回紹介するChatOpsの構築の際にも利用しています (C)MIXI
8. 概要（ChatOps）
9. 概要（ChatOps） • ターミナル実行での運用課題 • みんなのターミナル • 具体的な実装方法 (C)MIXI
10. ターミナル実行での運用課題
11. ターミナル上での作業（踏み台） • 不定期に必要となるスクリプト実行 ◦ 個別キャンペーン用のスクリプト ◦ 障害時の補填用スクリプト ◦ etc… • 障害の調査のために叩く各種コマンド (C)MIXI
12. コンテナ移行前（EC2）の実行フロー 1. 踏み台サーバーにSSH 2. 実行するコマンドをSlack上で共有 3. コマンド実行 (C)MIXI
13. ターミナル実行での運用課題 • Slack上で共有するとはいえ、実行自体はターミナル上なので、100% レビューしたコマンドが実行される保証はない • やろうと思えば何でもできてしまうために、意図せぬ問題が発生するリ スクが付きまとう • レビューしたとして、厳密な実行タイミングや結果をSlack上からは知る ことができない (C)MIXI
14. ターミナル実行での運用課題 • Slack上で共有するとはいえ、実行自体はターミナル上なので、100% レビューしたコマンドが実行される保証はない • やろうと思えば何でもできてしまうために、意図せぬ問題が発生するリ スクが付きまとう • レビューしたとして、厳密な実行タイミングや結果をSlack上からは知る ことができない (C)MIXI コンテナ移行の際に合わせて 改善したい
15. コンテナ移行後のターミナル上での作業 • redis-cliや不定期のスクリプトの実行などターミナル上での作業が一部 残る • 代替手段を用意するのに一手間かかるのと、継続的な保守やこれまで の文化を考えると、安直にターミナル上での作業の禁止も取りづらい (C)MIXI
16. みんなのターミナル
17. みんなのターミナル (C)MIXI
18. みんなのターミナル (C)MIXI
19. みんなのターミナル • Slackを介してコマンドを実行する仕組み • コマンド投稿からレビュー、実行までの流れを全てSlackで実施すること ができる • コマンドを投稿すると、botによりSlackの補完が効かないコードスニペッ ト形式でコマンドが提示され、承認ボタンで実行 (C)MIXI
20. 主な利点 • チャットベースなので、全てが履歴に残る • この履歴がコマンドごとにURLを発行できるため、共有しやすい • 誰がどのようなコマンドを実行しているか一目で分かる • そのために引継ぎや新しい人が入ってきた際の学習が容易となる • 用意されたフローに乗っかる必要があり自由度が低く、他人視点のレ ビューが容易のため、リスクが抑えられる (C)MIXI
21. 具体的な実装方法
22. (C)MIXI Socket Modeを 利用する形 https://github.com/SlackAPI/bolt-js
23. 承認までの仕組み (C)MIXI • 決められた形式でSlackに投稿する と、bolt側で承認するか否かの文言 と共に返信 • 自動リンクなどSlackの補完が効 き、意図しないコマンドが送られる 可能性があるので、コードスニペット 形式で返信される • また、一部パース処理も実施
24. パース処理 (C)MIXI
25. 承認後の仕組み (C)MIXI • 承認後はCloudWatch Logsのリン クを投稿 • できるだけSlack上に残したくない情 報がある場合の対策として削除ボタ ンを用意し、コマンドの投稿を削除 できるようにしている
26. インフラ構成 (C)MIXI
27. インフラ構成 (C)MIXI 重複実行の対策として、 コマンドとtimestampで 排他制御
28. GitHub Actions (C)MIXI
29. 自己紹介
30. 自己紹介 • 鈴木 雅也 (Masaya Suzuki) • 新卒4年目 / minimo 2年目 • minimoのサーバーサイドの開発やインフラの構築・運用を担当 • GitHub Actionsを触るのが好き • 著書 ◦ 数式をプログラムするってつまりこういうこと https://amzn.asia/d/bvqp5T5 ◦ データサイエンス100本ノック構造化データ加工編ガイドブック https://amzn.asia/d/gmgxaVk (C)MIXI
31. 概要（GitHub Actions）
32. 概要 (GitHub Actions) • self-hosted runner 導入 • PRを自動生成するCI導入 (C)MIXI
33. self-hosted runner 導入
34. self-hosted runner 導入: 課題 • minimoでは主にGitHub Actionsを使ってCIを動かしている • GitHub-hosted runnerのみの場合、以下の課題があった ◦ 並列数の上限が決まっている ◦ 契約プランの無料枠を超過し、追加課金が常態化 ◦ AWSのVPC内への接続を伴うCIを記述するのが難しい ◦ (話が持ち上がった当時は) マシンスペックが固定なので、処理が重いCIを動 かしづらい (C)MIXI
35. self-hosted runner 導入: 解決策・方針 • self-hosted runnerを導入する • 以下のCIをself-hosted runnerに移行する ◦ 実行時間がかかるCI ◦ AWSへの接続を伴うCI • 上記以外のCIは従来通りGitHub-hosted runnerで実行することで、 GitHubの無料枠を使い切る (C)MIXI
36. self-hosted runner 導入: 基本的な構築方法 • 特定のリポジトリで動かす場合、以下のように構築する 1. GitHubのアカウントでPersonal Access Tokenを作成する 2. 以下のようなDockerイメージをビルドする (C)MIXI FROM myoung34/github-runner RUN mkdir -p /path/to/work_dir
37. self-hosted runner 導入: 基本的な構築方法 • 特定のリポジトリで動かす場合、以下のように構築する 2. 以下のようにDockerコンテナを立ち上げる 3. (GitHub側でrunnerが自動的に登録される) (C)MIXI docker run --rm -e RUNNER_SCOPE=repo \ -e LABELS=CIのruns-onの値 (カンマ区切りで複数指定可) \ -e RUNNER_WORKDIR=/path/to/work_dir \ -e REPO_URL=GitHubリポジトリのURL \ -e ACCESS_TOKEN=GitHubのPersonal Access Token \ Dockerイメージ名
38. self-hosted runner 導入: 基本的な使用方法 • CIのruns-onを以下のように修正することで、self-hosted runnerを使 用できる • 手元の環境で簡単に試せる！ (C)MIXI … jobs: test: runs-on: LABELSで指定した値 ...
39. AWS Cloud ECR self-hosted runner 導入: アーキテクチャ (C)MIXI ECS on EC2 リポジトリA用Service Task数増減 CI起動・終了通知 定期実行 Task (Container) CI実行 リポジトリB用Service Amazon EventBridge AWS Lambda AWS Lambda Task入れ替え AWS Secrets Manager Payload検証用Secret取得 リポジトリA用Image リポジトリB用Image pull
40. self-hosted runner 導入: アーキテクチャ • AWSのECS上で構築 • ECS ◦ CI上でDockerを使うケースがあるため、起動タイプはEC2 ◦ 裏で動いているEC2インスタンスの増減はCapacity Providerで行う ◦ GitHubのリポジトリ単位でServiceを作り、その中でself-hosted runnerの Taskを動かす • ECR ◦ ECS Taskで使用するDockerイメージを管理 (C)MIXI
41. self-hosted runner 導入: アーキテクチャ • Lambda (Task数増減) ◦ 実行するCIの増減に合わせてECS Taskも増減する ◦ Function URLsでGitHubのWebhookによるCI起動・終了の通知を受け取り、 ECS ServiceのdesiredCountを増減させる ◦ WebhookのPayload認証にはSecret Managerに保存したSecretを使用 • Lambda (Task入れ替え) ◦ タスクがずっと残っていると不具合が発生することがあるので、定期的に入れ 替える ◦ 深夜にECS ServiceをforceNewDeploymentを設定した状態でdesiredCount を1にする (C)MIXI
42. self-hosted runner 導入: 工夫したポイント • Dockerイメージ・コンテナ関連 ◦ セキュリティ面を重視して、ベースイメージは少し枯れたバージョンを使用して いる ◦ CI実行後にTaskをスケールインさせるため、CIの実行が終わったらrunnerを 終了させる環境変数「EPHEMERAL=1」を指定している (C)MIXI
43. self-hosted runner 導入: 現状 • self-hosted runnerのインフラ構築完了 • CIをself-hosted runnerに移行中 ◦ self-hosted runner導入前に比べ、GitHubへの追加課金が1/4になっている (C)MIXI
44. self-hosted runner 導入: 導入してみてのメリット • self-hosted runnerに移行したCIについては並列数の上限がなくなった • AWSリソースを扱うCIを特別な処理なしで記述できるようになった • CIを動かすマシンを変えられるので、処理が重いCIに対し高スペックな マシンを割り当てられるようになった • CI実行に必要なコマンドのインストールをDockerイメージのビルド時に 行えるので、CIの実行時間のうちインストールにかかっていた時間を短 縮できた (C)MIXI
45. PRを自動生成するCI導入
46. PRを自動生成するCI導入: 課題 • minimoではサーバーサイドのGo移行を行っているが、そのリポジトリ にはGoのformatterやOpenAPIのYAML等からコードを自動生成する スクリプトが存在する • これらのツール・スクリプトを実行し忘れた状態でPRを立ててしまうこと がしばしば発生していた • Gitフックでコミット時にツール・スクリプトを実行するように設定すること も可能だが、個々の開発者が設定する必要がある (C)MIXI
47. PRを自動生成するCI導入: 解決策 • formatterやコード自動生成のスクリプトの実行結果を修正PRとして出 すCIを構築する • 修正コミットを追加するのではなくPRを出す形式にしているのは、一度 人の目を通すことで、意図しない差分が積まれるのを防ぐため (C)MIXI
48. PRを自動生成するCI導入: 構築方法 • プライベートの開発でも同様の課題があり、前述の解決策を簡単に導 入できるActions「dev-hato/actions-diff-pr-management」[1] を作成し ていたため、これを使用することにした (C)MIXI [1] https://github.com/marketplace/actions/diff-pr-management
49. PRを自動生成するCI導入: 構築方法 • 以下のような形でCIを記述する (C)MIXI on: pull_request: types: - opened - synchronize - reopened - closed jobs: diff-pr-management: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 if: github.event_name != 'pull_request' || github.event.action != 'closed' with: fetch-depth: 0 ref: ${{ github.event.pull_request.head.sha || github.sha }} - if: github.event_name != 'pull_request' || github.event.action != 'closed' run: hoge fmt - uses: dev-hato/actions-diff-pr-management@v1 with: github-token: ${{secrets.GITHUB_TOKEN}} formatterやスクリプトを実 行する Actionsを実行する
50. PRを自動生成するCI導入: 主な機能 • 修正PR作成 1. 修正差分があると以下のような形で修正PRが作られる (C)MIXI https://github.com/dev-hato/actions-diff-pr-management/pull/579
51. PRを自動生成するCI導入: 主な機能 • 修正PR作成 2. 修正差分をマージすると元のPRにマージされる (C)MIXI https://github.com/dev-hato/actions-diff-pr-management/pull/578
52. PRを自動生成するCI導入: 主な機能 • 修正PRのclose • 既に修正PRが出ている状態で元のPRに修正差分をコミットしたり、元のPRを closeしたりした場合は修正PRが自動的にcloseされる (C)MIXI https://github.com/dev-hato/actions-diff-pr-management/pull/453
53. PRを自動生成するCI導入: 導入してのメリット • PRベースで実装を行っている限り、開発者側で設定を行わなくても formatterやコード自動生成のスクリプトが適用されるようになった • minimoではインフラをコード (AWS CDK) で管理しているが、定期的に 不要なstaging環境を削除するCIもこのActionsを使って構築できた (C)MIXI
54. PRを自動生成するCI導入: Special Thanks • Actions「dev-hato/actions-diff-pr-management」を一緒に作り上げた Goryudyuma氏 [1] とこのActionsを作るきっかけを提供してくれたなっ かあ氏 [2] にこの場を借りてお礼申し上げます (C)MIXI [1] https://github.com/Goryudyuma [2] https://github.com/nakkaa