MIXI TECH CONFERENCE 2023 にてお話した洗川＆鈴木の資料です。
動画：https://youtu.be/irO5Yk1JvYE
https://techcon.mixi.co.jp/d3-2
minimo 事業部における開発基盤の整備（ChatOps + GitHub Actions）MIXI TECH CONFERENCE 2023DAY3 D3-2(C)MIXI
View Slide
概要● minimoについて● ChatOps● GitHub Actions(C)MIXI
minimoについて(C)MIXI
minimoについて● 1月で9周年を迎えたサービス● 美容師やネイリスト、アイデザイナー等を予約・検索できるアプリ● サロンスタッフと直接やり取りができる● 直近だと、パーソナルカラー診断のコンテンツを追加した(C)MIXIhttps://minimodel.jp/about
ChatOps(C)MIXI
自己紹介
自己紹介● 洗川 雄輝● 株式会社MIXI所属○ minimo事業部には2年半ほど前にJoin○ コンテナ移行、Go移行などを担当● よく触るのはAWS、Unity● OSS○ https://github.com/yukiarrr/ecsk○ ECSのタスク操作をインタラクティブにできるツール○ 今回紹介するChatOpsの構築の際にも利用しています(C)MIXI
概要（ChatOps）
概要（ChatOps）● ターミナル実行での運用課題● みんなのターミナル● 具体的な実装方法(C)MIXI
ターミナル実行での運用課題
ターミナル上での作業（踏み台）● 不定期に必要となるスクリプト実行○ 個別キャンペーン用のスクリプト○ 障害時の補填用スクリプト○ etc…● 障害の調査のために叩く各種コマンド(C)MIXI
コンテナ移行前（EC2）の実行フロー1. 踏み台サーバーにSSH2. 実行するコマンドをSlack上で共有3. コマンド実行(C)MIXI
ターミナル実行での運用課題● Slack上で共有するとはいえ、実行自体はターミナル上なので、100%レビューしたコマンドが実行される保証はない● やろうと思えば何でもできてしまうために、意図せぬ問題が発生するリスクが付きまとう● レビューしたとして、厳密な実行タイミングや結果をSlack上からは知ることができない(C)MIXI
ターミナル実行での運用課題● Slack上で共有するとはいえ、実行自体はターミナル上なので、100%レビューしたコマンドが実行される保証はない● やろうと思えば何でもできてしまうために、意図せぬ問題が発生するリスクが付きまとう● レビューしたとして、厳密な実行タイミングや結果をSlack上からは知ることができない(C)MIXIコンテナ移行の際に合わせて改善したい
コンテナ移行後のターミナル上での作業● redis-cliや不定期のスクリプトの実行などターミナル上での作業が一部残る● 代替手段を用意するのに一手間かかるのと、継続的な保守やこれまでの文化を考えると、安直にターミナル上での作業の禁止も取りづらい(C)MIXI
みんなのターミナル
みんなのターミナル(C)MIXI
みんなのターミナル● Slackを介してコマンドを実行する仕組み● コマンド投稿からレビュー、実行までの流れを全てSlackで実施することができる● コマンドを投稿すると、botによりSlackの補完が効かないコードスニペット形式でコマンドが提示され、承認ボタンで実行(C)MIXI
主な利点● チャットベースなので、全てが履歴に残る● この履歴がコマンドごとにURLを発行できるため、共有しやすい● 誰がどのようなコマンドを実行しているか一目で分かる● そのために引継ぎや新しい人が入ってきた際の学習が容易となる● 用意されたフローに乗っかる必要があり自由度が低く、他人視点のレビューが容易のため、リスクが抑えられる(C)MIXI
具体的な実装方法
(C)MIXISocket Modeを利用する形https://github.com/SlackAPI/bolt-js
承認までの仕組み(C)MIXI● 決められた形式でSlackに投稿すると、bolt側で承認するか否かの文言と共に返信● 自動リンクなどSlackの補完が効き、意図しないコマンドが送られる可能性があるので、コードスニペット形式で返信される● また、一部パース処理も実施
パース処理(C)MIXI
承認後の仕組み(C)MIXI● 承認後はCloudWatch Logsのリンクを投稿● できるだけSlack上に残したくない情報がある場合の対策として削除ボタンを用意し、コマンドの投稿を削除できるようにしている
インフラ構成(C)MIXI
インフラ構成(C)MIXI重複実行の対策として、コマンドとtimestampで排他制御
GitHub Actions(C)MIXI
自己紹介● 鈴木 雅也 (Masaya Suzuki)● 新卒4年目 / minimo 2年目● minimoのサーバーサイドの開発やインフラの構築・運用を担当● GitHub Actionsを触るのが好き● 著書○ 数式をプログラムするってつまりこういうことhttps://amzn.asia/d/bvqp5T5○ データサイエンス100本ノック構造化データ加工編ガイドブックhttps://amzn.asia/d/gmgxaVk(C)MIXI
概要（GitHub Actions）
概要 (GitHub Actions)● self-hosted runner 導入● PRを自動生成するCI導入(C)MIXI
self-hosted runner 導入
self-hosted runner 導入: 課題● minimoでは主にGitHub Actionsを使ってCIを動かしている● GitHub-hosted runnerのみの場合、以下の課題があった○ 並列数の上限が決まっている○ 契約プランの無料枠を超過し、追加課金が常態化○ AWSのVPC内への接続を伴うCIを記述するのが難しい○ (話が持ち上がった当時は) マシンスペックが固定なので、処理が重いCIを動かしづらい(C)MIXI
self-hosted runner 導入: 解決策・方針● self-hosted runnerを導入する● 以下のCIをself-hosted runnerに移行する○ 実行時間がかかるCI○ AWSへの接続を伴うCI● 上記以外のCIは従来通りGitHub-hosted runnerで実行することで、GitHubの無料枠を使い切る(C)MIXI
self-hosted runner 導入: 基本的な構築方法● 特定のリポジトリで動かす場合、以下のように構築する1. GitHubのアカウントでPersonal Access Tokenを作成する2. 以下のようなDockerイメージをビルドする(C)MIXIFROM myoung34/github-runnerRUN mkdir -p /path/to/work_dir
self-hosted runner 導入: 基本的な構築方法● 特定のリポジトリで動かす場合、以下のように構築する2. 以下のようにDockerコンテナを立ち上げる3. (GitHub側でrunnerが自動的に登録される)(C)MIXIdocker 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イメージ名
self-hosted runner 導入: 基本的な使用方法● CIのruns-onを以下のように修正することで、self-hosted runnerを使用できる● 手元の環境で簡単に試せる！(C)MIXI…jobs:test:runs-on: LABELSで指定した値...
AWS CloudECRself-hosted runner 導入: アーキテクチャ(C)MIXIECS on EC2リポジトリA用ServiceTask数増減CI起動・終了通知定期実行Task (Container)CI実行リポジトリB用ServiceAmazon EventBridgeAWS LambdaAWS LambdaTask入れ替えAWS Secrets ManagerPayload検証用Secret取得リポジトリA用ImageリポジトリB用Imagepull
self-hosted runner 導入: アーキテクチャ● AWSのECS上で構築● ECS○ CI上でDockerを使うケースがあるため、起動タイプはEC2○ 裏で動いているEC2インスタンスの増減はCapacity Providerで行う○ GitHubのリポジトリ単位でServiceを作り、その中でself-hosted runnerのTaskを動かす● ECR○ ECS Taskで使用するDockerイメージを管理(C)MIXI
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
self-hosted runner 導入: 工夫したポイント● Dockerイメージ・コンテナ関連○ セキュリティ面を重視して、ベースイメージは少し枯れたバージョンを使用している○ CI実行後にTaskをスケールインさせるため、CIの実行が終わったらrunnerを終了させる環境変数「EPHEMERAL=1」を指定している(C)MIXI
self-hosted runner 導入: 現状● self-hosted runnerのインフラ構築完了● CIをself-hosted runnerに移行中○ self-hosted runner導入前に比べ、GitHubへの追加課金が1/4になっている(C)MIXI
self-hosted runner 導入: 導入してみてのメリット● self-hosted runnerに移行したCIについては並列数の上限がなくなった● AWSリソースを扱うCIを特別な処理なしで記述できるようになった● CIを動かすマシンを変えられるので、処理が重いCIに対し高スペックなマシンを割り当てられるようになった● CI実行に必要なコマンドのインストールをDockerイメージのビルド時に行えるので、CIの実行時間のうちインストールにかかっていた時間を短縮できた(C)MIXI
PRを自動生成するCI導入
PRを自動生成するCI導入: 課題● minimoではサーバーサイドのGo移行を行っているが、そのリポジトリにはGoのformatterやOpenAPIのYAML等からコードを自動生成するスクリプトが存在する● これらのツール・スクリプトを実行し忘れた状態でPRを立ててしまうことがしばしば発生していた● Gitフックでコミット時にツール・スクリプトを実行するように設定することも可能だが、個々の開発者が設定する必要がある(C)MIXI
PRを自動生成するCI導入: 解決策● formatterやコード自動生成のスクリプトの実行結果を修正PRとして出すCIを構築する● 修正コミットを追加するのではなくPRを出す形式にしているのは、一度人の目を通すことで、意図しない差分が積まれるのを防ぐため(C)MIXI
PRを自動生成するCI導入: 構築方法● プライベートの開発でも同様の課題があり、前述の解決策を簡単に導入できるActions「dev-hato/actions-diff-pr-management」[1] を作成していたため、これを使用することにした(C)MIXI[1] https://github.com/marketplace/actions/diff-pr-management
PRを自動生成するCI導入: 構築方法● 以下のような形でCIを記述する(C)MIXIon:pull_request:types:- opened- synchronize- reopened- closedjobs:diff-pr-management:runs-on: ubuntu-lateststeps:- uses: actions/[email protected]if: github.event_name != 'pull_request' || github.event.action != 'closed'with:fetch-depth: 0ref: ${{ github.event.pull_request.head.sha || github.sha }}- if: github.event_name != 'pull_request' || github.event.action != 'closed'run: hoge fmt- uses: dev-hato/[email protected]with:github-token: ${{secrets.GITHUB_TOKEN}}formatterやスクリプトを実行するActionsを実行する
PRを自動生成するCI導入: 主な機能● 修正PR作成1. 修正差分があると以下のような形で修正PRが作られる(C)MIXIhttps://github.com/dev-hato/actions-diff-pr-management/pull/579
PRを自動生成するCI導入: 主な機能● 修正PR作成2. 修正差分をマージすると元のPRにマージされる(C)MIXIhttps://github.com/dev-hato/actions-diff-pr-management/pull/578
PRを自動生成するCI導入: 主な機能● 修正PRのclose● 既に修正PRが出ている状態で元のPRに修正差分をコミットしたり、元のPRをcloseしたりした場合は修正PRが自動的にcloseされる(C)MIXIhttps://github.com/dev-hato/actions-diff-pr-management/pull/453
PRを自動生成するCI導入: 導入してのメリット● PRベースで実装を行っている限り、開発者側で設定を行わなくてもformatterやコード自動生成のスクリプトが適用されるようになった● minimoではインフラをコード (AWS CDK) で管理しているが、定期的に不要なstaging環境を削除するCIもこのActionsを使って構築できた(C)MIXI
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
mixi_engineers
sakaguchi
tarappo
salaboy
moritamasami
victorrentea
matyuda
ojun9
sinsoku
_takahash
niryuu
jfg956
addyosmani
62gerente
cassininazir
keithpitt
shpigford
marktimemedia
michaelherold
holman
pauljervisheath
tanoku
jponch
geeforr