[JA] Mercari Server-Side Deployment: Present and Future

Transcript

1. Mercari Tech Conf 2017 Software Engineer (SRE) Kenichi SASAKI Mercariサーバサイドデプロイ: 現在と未来
2. 自己紹介 Kenichi Sasaki (@siroken3) Software Engineer (SRE) Mercari, Inc (2014/7〜)
3. SRE • Site Reliability Engineeringの略 • Google の運用チームを率いる Ben Treynorが提唱 • Googleの様々なプロダクト・サービスを横断して、ソフトウェアエンジニアリン グよりサイト/サービスの信頼性を向上させる Software Engineering/Team とその実践 = Google SRE
4. Mercari SRE • いつでも快適かつ安全に利用できる「信頼性の高い」サービスの実現 • 「新規サービスの開発以外のエンジニアリングは全部やる」 • 2015/11 「インフラチーム」からSREへ • 「インフラ」よりもサービス指向 • 現在メンバーは「10人」絶賛募集中
5. Mercariサーバサイドデプロイ
6. Mercariのサーバサイドデプロイ要件 • Continuous Delivery • 10件以上/Day • GitHub Pull requestベース開発 • Production環境にはPull requestで適用 • Masterブランチにマージ = Production Deploy • デプロイ前確認 • Peerレビューされていること • Database Migration完了していること • マネージャのリリース承認受けていること master
7. デプロイ確認について • プロダクション品質保証の観点 • チケットに紐付いていること • ピアレビューを実施していること • いつ、何をリリースしたのか振り返ることができること • リリース時事故防止の観点 • DBMigration (コードに必要なDBのTableあるいはレコード)が実施されていることを保証 • ピアレビュー実施後にコード修正が入った場合再レビューしていること
8. Before Automation (〜2015)
9. ローンチ直後〜2015/2/17 • 1週間に1度の定期Deploy • 1度にDeployする内容が増えすぎた • ロールバックかDeploy継続かの判断難 しい • 毎日が緊急Deploy • 平日(月〜木曜)はDeployDay • DeployしたいPull requestをホワイト ボードに記載 • Deploy当番制 • リリース要件を満たしているかどう か目視チェック • ansible-playbook実行
10. After Automation (2015〜2017)
11. Key Features • Slack botによる自動化 • Deployの全てをSlack上で実行可能 • Google Calendarとの連携 • リリース予定を設定できる • Pull requestを確認 • DescriptionにredmineチケットのURLが記述? • redmineでマネージャ承認済みステータス ? • ソース差分にSQLファイルがあるか • DBMigration必須にする • LGTMラベルをPR作成者以外がつけているか • peerレビューを実施した証拠
12. Deploy Overview (1st Generation) :Google Calendar :Redmine :API Servers :API Servers :API Servers 1-1:git push 2-2:approve? 1b-1:approve <<Developer>> <<Manager>> 2-4:comment(“deploy done”) :GitHub Deploy bot: Slack bot 2-3:deploy() 2-5:entry(“deploy done”) 2-1:entry(DeployDATE)
13. After Automation 2nd Generation (2017〜)
14. Key Features • デプロイBotとITGCレビューBotに分離 • 今後デプロイ手段増加するため • GitHub review bot • GitHubでソースのレビューを行う bot • PullRequestを確認 • DescriptionにJIRA Issueリンクがあるか • masterブランチを対象にしていないPRは レビューしない • GitHub Integrations & services • Amazon SNS • AWS Lambda
15. Review bot: AWS Lambda Deploy Overview (2nd Generation) :Google Calendar :JIRA :API Servers :API Servers :API Servers <<Amazon SNS>> 1a-2:event(:Pullrequest) 1a-1:git push / comment 1a-3:result := review(:PullRequest) 1a-4:approve? 1a-5: review(:result) 1b-1:approve <<Developer>> <<Manager>> 2-2: comment(“review please”) 2-4:comment(“deploy done”) :GitHub Deploy bot: Slack bot 2-3:deploy() 2-5:entry(“deploy done”) 2-1:entry(DeployDATE)
16. AWS Review Bot Amazon SNS Lambda function JIRA Human Resource DB
17. Deploy server Deploy Bot Server slack RTM bot ansible-playbook リポジトリ名#1.yml リポジトリ名#2.yml リポジトリ名#N.yml
18. GitHub Review Bot • AWS Lambda + SNS • npm github • Preview版APIも使える • GraphQLなv4には未対 応 // eval_items: {approve: , body: } を返すPromise // p_r: Amazon SNS で受信したPullRequest object (eval_items, p_r) => { Promise.all(eval_items) .then(results => { let approve = results.map(r => { return r.approve; }) .reduce((x,y) => { return x && y; }); let body = approve ? MSG_OK : MSG_NG; return github.pullRequests.createReview({ owner: ‘xxxx’, repo: p_r.head.repo.name, number: p_r.number, body: body, event: approve ? ‘APPROVE’ : ‘REQUEST_CHANGES’ }) }); }
19. 自己P-R Label確認 • github.issues.getEventsにてラ ベルを付与/剥がした履歴が eventとして取得できる • event.actor.loginと p_r.user.loginを比較 (p_r) => { return github.issues.getEvents({ owner: ‘xxxx’, repo: p_r.head.repo.name, number: p_r.number }).then(resp => { // get last event let last_ev = resp.filter(ev => { ev.event == ‘labeled’ && Ev.label.name == ‘LGTM’ }).reverse()[0]; if (last_ev.actor.login == p_r.user.login) { return {approve: false, body: ‘Self Labeled’}; } else { return {approve: true, body: ‘OK’}; } }); }
20. GitHub Bot ユーザ体験について
21. 以下のイベントをトリガに動作 • Pull request作成 • Pull requestコメント記述 • ソースpush • ラベルの添付/削除 • Peerレビュー済み • DBMigration済み
22. 初期版 ステータス欄に結果を表示するよ うにした 開発者からCIテストの結果と一緒 だと見づらい声
23. β2版 レビューコメントに結果を記述す るようにした。 pushするたびにタイムラインが汚 れてうるさいの声
24. β2版 (続) NOT_IT_CONTROLラベルはチ ケットと紐付いていなくてもよい軽 い修正であることを示す Pull requestの変更に含まれる ファイルの種類で判断 ラベルは自動的に付与
25. 現行版 Pull requestが作られたらすぐに botレビュー開始 すぐに結果の詳細を表示しない。 開発者のコメント(review please) で詳細なレビュー結果を表示
26. ユーザ体験を意識したGitHub Botまとめ • 開発者(=ユーザ)の邪魔をしないこと • 主役は開発者 • そっと見守る影としての存在 • 情報は最小限に。聞かれたら詳細を応える程度 • 課題 • 稼働しているのか開発者が不安になることもある
27. そして Microservices
28. kubernetes(k8s)に対応したDeploy • Microservicesの実現方法 • k8sを基盤に選定 • Spinnakerの採用を始めた • Continuous Delivery Platform • Netflixで開発 • Googleと共同作業し2015年にOSS化 • Microservicesとの関係 • 開発者によりDeploymentパイプラインをOwnershipを持って「開発」できる
29. Spinnaker • 期待 • Pipeline を構成しさまざまなスタイルの Deployが行える • Automated Canary Analysisに期待 • 課題 • 設定GUIベース • Configration as Code PullRequestレビュー/履歴管理したい • コミュニティ始まったばかりでトラブルシューティング情報少ない • バージョンupdate時によく壊れる
30. https://blog.spinnaker.io/can-i-push-that-building-safer-low-risk-deployments-with-spinnaker-a27290847ac4
31. (近)未来
32. デプロイの(近)未来
33. デプロイの(近)未来 • オペレーションの改善 • 自動化推進 • Spinnaker Deployの社内普及 • データDeploy • 機械学習データ • 可視化 • エンジニア向けだけでない • CSチームにもそのまま共有できる https://flic.kr/p/BKp7yQ
34. 参考情報 • Mercari Engineering Blog • http://tech.mercari.com/entry/2015/10/15/183000 • http://tech.mercari.com/entry/2016/11/14/120000 • Kubernetes • https://kubernetes.io/ • Spinnaker • https://www.spinnaker.io/ • http://tech.mercari.com/entry/2017/08/21/092743 • GitHub REST API v3 • https://developer.github.com/v3/ • npm github • https://www.npmjs.com/package/github • http://mikedeboer.github.io/node-github/ • https://developer.github.com/v3/
35. Thank You