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

Slide 1

Slide 1 text

minimo 事業部における開発基盤の整備（ChatOps + GitHub Actions） MIXI TECH CONFERENCE 2023 DAY3 D3-2 (C)MIXI

Slide 2

Slide 2 text

概要 ● minimoについて ● ChatOps ● GitHub Actions (C)MIXI

Slide 3

Slide 3 text

minimoについて (C)MIXI

Slide 4

Slide 4 text

minimoについて ● 1月で9周年を迎えたサービス ● 美容師やネイリスト、アイデザイナー等を予約・検索できるアプリ ● サロンスタッフと直接やり取りができる ● 直近だと、パーソナルカラー診断のコンテンツを追加した (C)MIXI https://minimodel.jp/about

Slide 5

Slide 5 text

ChatOps (C)MIXI

Slide 6

Slide 6 text

自己紹介

Slide 7

Slide 7 text

自己紹介 ● 洗川雄輝 ● 株式会社MIXI所属 ○ minimo事業部には2年半ほど前にJoin ○ コンテナ移行、Go移行などを担当 ● よく触るのはAWS、Unity ● OSS ○ https://github.com/yukiarrr/ecsk ○ ECSのタスク操作をインタラクティブにできるツール ○ 今回紹介するChatOpsの構築の際にも利用しています (C)MIXI

Slide 8

Slide 8 text

概要（ChatOps）

Slide 9

Slide 9 text

概要（ChatOps） ● ターミナル実行での運用課題 ● みんなのターミナル ● 具体的な実装方法 (C)MIXI

Slide 10

Slide 10 text

ターミナル実行での運用課題

Slide 11

Slide 11 text

ターミナル上での作業（踏み台） ● 不定期に必要となるスクリプト実行 ○ 個別キャンペーン用のスクリプト ○ 障害時の補填用スクリプト ○ etc… ● 障害の調査のために叩く各種コマンド (C)MIXI

Slide 12

Slide 12 text

コンテナ移行前（EC2）の実行フロー 1. 踏み台サーバーにSSH 2. 実行するコマンドをSlack上で共有 3. コマンド実行 (C)MIXI

Slide 13

Slide 13 text

ターミナル実行での運用課題 ● Slack上で共有するとはいえ、実行自体はターミナル上なので、100% レビューしたコマンドが実行される保証はない ● やろうと思えば何でもできてしまうために、意図せぬ問題が発生するリスクが付きまとう ● レビューしたとして、厳密な実行タイミングや結果をSlack上からは知ることができない (C)MIXI

Slide 14

Slide 14 text

Slide 15

Slide 15 text

コンテナ移行後のターミナル上での作業 ● redis-cliや不定期のスクリプトの実行などターミナル上での作業が一部残る ● 代替手段を用意するのに一手間かかるのと、継続的な保守やこれまでの文化を考えると、安直にターミナル上での作業の禁止も取りづらい (C)MIXI

Slide 16

Slide 16 text

みんなのターミナル

Slide 17

Slide 17 text

みんなのターミナル (C)MIXI

Slide 18

Slide 18 text

みんなのターミナル (C)MIXI

Slide 19

Slide 19 text

みんなのターミナル ● Slackを介してコマンドを実行する仕組み ● コマンド投稿からレビュー、実行までの流れを全てSlackで実施することができる ● コマンドを投稿すると、botによりSlackの補完が効かないコードスニペット形式でコマンドが提示され、承認ボタンで実行 (C)MIXI

Slide 20

Slide 20 text

主な利点 ● チャットベースなので、全てが履歴に残る ● この履歴がコマンドごとにURLを発行できるため、共有しやすい ● 誰がどのようなコマンドを実行しているか一目で分かる ● そのために引継ぎや新しい人が入ってきた際の学習が容易となる ● 用意されたフローに乗っかる必要があり自由度が低く、他人視点のレビューが容易のため、リスクが抑えられる (C)MIXI

Slide 21

Slide 21 text

具体的な実装方法

Slide 22

Slide 22 text

(C)MIXI Socket Modeを利用する形 https://github.com/SlackAPI/bolt-js

Slide 23

Slide 23 text

承認までの仕組み (C)MIXI ● 決められた形式でSlackに投稿すると、bolt側で承認するか否かの文言と共に返信 ● 自動リンクなどSlackの補完が効き、意図しないコマンドが送られる可能性があるので、コードスニペット形式で返信される ● また、一部パース処理も実施

Slide 24

Slide 24 text

パース処理 (C)MIXI

Slide 25

Slide 25 text

承認後の仕組み (C)MIXI ● 承認後はCloudWatch Logsのリンクを投稿 ● できるだけSlack上に残したくない情報がある場合の対策として削除ボタンを用意し、コマンドの投稿を削除できるようにしている

Slide 26

Slide 26 text

インフラ構成 (C)MIXI

Slide 27

Slide 27 text

インフラ構成 (C)MIXI 重複実行の対策として、コマンドとtimestampで排他制御

Slide 28

Slide 28 text

GitHub Actions (C)MIXI

Slide 29

Slide 29 text

自己紹介

Slide 30

Slide 30 text

自己紹介 ● 鈴木雅也 (Masaya Suzuki) ● 新卒4年目 / minimo 2年目 ● minimoのサーバーサイドの開発やインフラの構築・運用を担当 ● GitHub Actionsを触るのが好き ● 著書 ○ 数式をプログラムするってつまりこういうこと https://amzn.asia/d/bvqp5T5 ○ データサイエンス100本ノック構造化データ加工編ガイドブック https://amzn.asia/d/gmgxaVk (C)MIXI

Slide 31

Slide 31 text

概要（GitHub Actions）

Slide 32

Slide 32 text

概要 (GitHub Actions) ● self-hosted runner 導入 ● PRを自動生成するCI導入 (C)MIXI

Slide 33

Slide 33 text

self-hosted runner 導入

Slide 34

Slide 34 text

self-hosted runner 導入: 課題 ● minimoでは主にGitHub Actionsを使ってCIを動かしている ● GitHub-hosted runnerのみの場合、以下の課題があった ○ 並列数の上限が決まっている ○ 契約プランの無料枠を超過し、追加課金が常態化 ○ AWSのVPC内への接続を伴うCIを記述するのが難しい ○ (話が持ち上がった当時は) マシンスペックが固定なので、処理が重いCIを動かしづらい (C)MIXI

Slide 35

Slide 35 text

self-hosted runner 導入: 解決策・方針 ● self-hosted runnerを導入する ● 以下のCIをself-hosted runnerに移行する ○ 実行時間がかかるCI ○ AWSへの接続を伴うCI ● 上記以外のCIは従来通りGitHub-hosted runnerで実行することで、 GitHubの無料枠を使い切る (C)MIXI

Slide 36

Slide 36 text

self-hosted runner 導入: 基本的な構築方法 ● 特定のリポジトリで動かす場合、以下のように構築する 1. GitHubのアカウントでPersonal Access Tokenを作成する 2. 以下のようなDockerイメージをビルドする (C)MIXI FROM myoung34/github-runner RUN mkdir -p /path/to/work_dir

Slide 37

Slide 37 text

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イメージ名

Slide 38

Slide 38 text

self-hosted runner 導入: 基本的な使用方法 ● CIのruns-onを以下のように修正することで、self-hosted runnerを使用できる ● 手元の環境で簡単に試せる！ (C)MIXI … jobs: test: runs-on: LABELSで指定した値 ...

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

self-hosted runner 導入: アーキテクチャ ● AWSのECS上で構築 ● ECS ○ CI上でDockerを使うケースがあるため、起動タイプはEC2 ○ 裏で動いているEC2インスタンスの増減はCapacity Providerで行う ○ GitHubのリポジトリ単位でServiceを作り、その中でself-hosted runnerの Taskを動かす ● ECR ○ ECS Taskで使用するDockerイメージを管理 (C)MIXI

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

self-hosted runner 導入: 工夫したポイント ● Dockerイメージ・コンテナ関連 ○ セキュリティ面を重視して、ベースイメージは少し枯れたバージョンを使用している ○ CI実行後にTaskをスケールインさせるため、CIの実行が終わったらrunnerを終了させる環境変数「EPHEMERAL=1」を指定している (C)MIXI

Slide 43

Slide 43 text

self-hosted runner 導入: 現状 ● self-hosted runnerのインフラ構築完了 ● CIをself-hosted runnerに移行中 ○ self-hosted runner導入前に比べ、GitHubへの追加課金が1/4になっている (C)MIXI

Slide 44

Slide 44 text

self-hosted runner 導入: 導入してみてのメリット ● self-hosted runnerに移行したCIについては並列数の上限がなくなった ● AWSリソースを扱うCIを特別な処理なしで記述できるようになった ● CIを動かすマシンを変えられるので、処理が重いCIに対し高スペックなマシンを割り当てられるようになった ● CI実行に必要なコマンドのインストールをDockerイメージのビルド時に行えるので、CIの実行時間のうちインストールにかかっていた時間を短縮できた (C)MIXI

Slide 45

Slide 45 text

PRを自動生成するCI導入

Slide 46

Slide 46 text

PRを自動生成するCI導入: 課題 ● minimoではサーバーサイドのGo移行を行っているが、そのリポジトリにはGoのformatterやOpenAPIのYAML等からコードを自動生成するスクリプトが存在する ● これらのツール・スクリプトを実行し忘れた状態でPRを立ててしまうことがしばしば発生していた ● Gitフックでコミット時にツール・スクリプトを実行するように設定することも可能だが、個々の開発者が設定する必要がある (C)MIXI

Slide 47

Slide 47 text

PRを自動生成するCI導入: 解決策 ● formatterやコード自動生成のスクリプトの実行結果を修正PRとして出すCIを構築する ● 修正コミットを追加するのではなくPRを出す形式にしているのは、一度人の目を通すことで、意図しない差分が積まれるのを防ぐため (C)MIXI

Slide 48

Slide 48 text

PRを自動生成するCI導入: 構築方法 ● プライベートの開発でも同様の課題があり、前述の解決策を簡単に導入できるActions「dev-hato/actions-diff-pr-management」[1] を作成していたため、これを使用することにした (C)MIXI [1] https://github.com/marketplace/actions/diff-pr-management

Slide 49

Slide 49 text

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を実行する

Slide 50

Slide 50 text

PRを自動生成するCI導入: 主な機能 ● 修正PR作成 1. 修正差分があると以下のような形で修正PRが作られる (C)MIXI https://github.com/dev-hato/actions-diff-pr-management/pull/579

Slide 51

Slide 51 text

PRを自動生成するCI導入: 主な機能 ● 修正PR作成 2. 修正差分をマージすると元のPRにマージされる (C)MIXI https://github.com/dev-hato/actions-diff-pr-management/pull/578

Slide 52

Slide 52 text

PRを自動生成するCI導入: 主な機能 ● 修正PRのclose ● 既に修正PRが出ている状態で元のPRに修正差分をコミットしたり、元のPRを closeしたりした場合は修正PRが自動的にcloseされる (C)MIXI https://github.com/dev-hato/actions-diff-pr-management/pull/453

Slide 53

Slide 53 text

PRを自動生成するCI導入: 導入してのメリット ● PRベースで実装を行っている限り、開発者側で設定を行わなくても formatterやコード自動生成のスクリプトが適用されるようになった ● minimoではインフラをコード (AWS CDK) で管理しているが、定期的に不要なstaging環境を削除するCIもこのActionsを使って構築できた (C)MIXI

Slide 54

Slide 54 text

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