What has been realized to improve maintainability at "Eight".

【福岡】GMOペパボ × Sansan合同勉強会 「歴史ある大規模サービスがまだなお成長する秘訣」 - connpass https://sansan.connpass.com/event/71727/
で発表した資料です。

Transcript

1. Eightがサーバーサイド/インフラの メンテナンス性向上のために実現 してきたこと
2. # sansan_gmopepabo ຊ೔ͷϋογϡλά
3. エンジニアの王国から来ました https://slack.com/intl/ja-jp/customer-stories/sansan
4. 菅井祐太朗 (@hokkai7go) Sansan株式会社 Eight事業部 インフラエンジニア • Chef実践⼊⾨ • Railsエンジニアの横にいる歴 5年 • サーバーをレス化する際の権限まわ りをあれこれすることが増えた • ⼀般社団法⼈LOCAL 理事
5. ビジネスの出会いを資産に変え、 働き⽅を⾰新する Mission
6. Your business network
7. 本発表について Eightがサーバーサイド/インフラのメンテナンス性向上のために実現してきたこと について事業部全体や、チーム内での取り組みについて紹介します
8. 秘訣 7
9. 必要なタイミングで 捨てたり作り直したりできること なのかなと
10. アジェンダ 9
11. チーム体制 監視システム リリース アプリケーションログの収集、分析 サーバーレス化
12. チーム体制 11
13. 7チーム * 4~5名くらい 合計 35名程度のエンジニア
14. バックエンド開発 5チーム モバイル(iOS, Android) 1チーム 基盤チーム 1チーム ← ココ
15. 基盤チーム Railsエンジニア * 3 インフラエンジニア * 2
16. チームがフォーカスしていること: インフラ、セキュリティ、パフォーマンス、 開発者全体の⽣産性向上
17. 監視システム 16
18. 2017年1⽉ Nagios→Mackerelに完全移⾏
20. Mackerelでやれることはだいたいやってる が、独⾃でやっているものもある
21. AWS Integrationで取れないメトリクスの取得、監視 粒度の細かいリソースに関するメトリクス⾃動取得 →監視に関わるLambdaが4つほど
22. AWS Integrationで取れないメトリクスの取得、監視 Auroraのinnodb status DynamoDBのキャパシティ消費率計算、監視 SESのbounse率計算、監視
23. 例: DynamoDBのキャパシティ消費率計算、監視 CloudWatch APIを叩き、Read/Write Capacityの使⽤率を計算 Mackerelに consumed_[read/write]_ratio としてメトリクスを投稿し、監視を設定
24. 粒度の細かいリソースに関するメトリクス⾃動取得 DynamoDB Stream Kinesis StreamのShard →増えたときにモニタリング追加が漏れそうなもの CloudWatch APIで取得、Mackerelに投稿
25. Lambdaの他にもIAM権限はTerraformで管理し インフラもコードで管理し、⽇々PR出してます
26. リリース 25
27. これまで、リリースについては いくつかの問題点有り
28. 問題点 デプロイを複数に分けて⾏う必要があった リリース⽅法が⼀本化されていない部分があった ⼿作業が多かった リリースにかかる時間が⻑かった(ひどいと2~3時間)
29. 対策として⾏ったこと
30. 対策の動き リリース所要時間計測 リリース改善の機運の⾼まり リリース⽅法の⼀本化 リリースブランチPR⾃動作成botの導⼊ デプロイとassets:precompileの分離 Golden Image(AMI)作成⾃動化 Autoscalingの導⼊ Blue/Green Deploymentの導⼊ 設定ファイルの簡略化
31. 対策の動き リリース所要時間計測 リリース改善の機運の⾼まり リリース⽅法の⼀本化 リリースブランチPR⾃動作成botの導⼊ デプロイとassets:precompileの分離 Golden Image(AMI)作成⾃動化 Autoscalingの導⼊ Blue/Green Deploymentの導⼊ 設定ファイルの簡略化
32. リリースブランチPR⾃動作成botの導⼊ リリースは⽕⽊の昼頃 リリースブランチPR作成をLambdaが⾃動的にやっている →リリース担当の⼿間を削減 Slackを⾒られれば、その⽇のリリースPRがわかる
33. デプロイとassets:precompileの分離 これまでデプロイ時にWebサーバ全台で assets:precompileを⾏っていた ↓ デプロイサーバでのデプロイ時にS3へアップロード、CloudFrontで配信
34. Golden Image(AMI)作成⾃動化 GitHubでmasterブランチをマージ Applicationデプロイ済み(全部⼊り)のイメージが⾃動的に出来上がる Slackにリリースコマンドが提⽰される →次の⼀步は、⾃動でリリースかな？
35. Golden Image(AMI)作成⾃動化
36. Blue/Green Deploymentの導⼊ おなじみのMartin Fowler⽒が提唱した概念 ・Golden Image作成⾃動化 ・Autoscaling導⼊ ・アプリケーションログ収集(後述) が整備されたことで準備が整った https://martinfowler.com/bliki/BlueGreenDeployment.html
37. リリースの改善についてのまとめ ・⼿作業をほぼ撲滅できた ・リリース内容に左右されてリリース時間が延びることはなくなった ・所要時間のうち待ち時間の割合がかなり増えた ・リリース担当から、リリース作業がかなり楽になったとの喜びの声
38. アプリケーションログ収集、分析 37
39. アプリケーションログも いくつか課題があった
40. アプリケーションログに関する課題 ・ログレベルがまちまち ・不要なログが⼤量に出ていた ・分析⼿段も⽤意できてなかったため、調査のコストがとても⾼い ・サーバへログインしなくてはならない状況 ・セキュリティ的懸念 ・運⽤事故を⽣む懸念
41. アプリケーションログに関してやったこと ・容量、⾏数の計測 ・削減⽬標を決めた ・不要そうなログをざっくりまとめた ・ログレベルの整理 ・⼈海戦術で不要ログ出⼒を⽌めた ・fluentdで収集、Elasticsearch→Kibanaで可視化、分析可能に
42. サーバーレス化 41
43. https://goo.gl/1dnUeH
44. https://goo.gl/2U8i58
45. リアルタイムなリコメンデーション をサーバーレスで実現した
46. リコメンデーションシステムの概略図
47. フィードのOGP画像リサイズ&キャッシュ をサーバーレスで実現した
48. OGP画像リサイズ&キャッシュシステムの概略図
49. Feed OGPը૾ ϦαΠζ&Ωϟογϡ Ϧίϝϯσʔγϣϯ ΞϓϦέʔγϣϯຊମ
50. サーバーレスの適⽤範囲 ・リアルタイムリコメンデーション ・フィードのOGP画像のリサイズ&キャッシュ機構 ・監視システムの⼀部 →イベントドリブンな処理で今後も適⽤範囲が広がるだろう システムを分割することでソースコード、リリースなどの依存性を少なくし ある程度まではメンテナンス性向上につながる
51. Feed OGPը૾ ϦαΠζ&Ωϟογϡ Ϧίϝϯσʔγϣϯ ΞϓϦέʔγϣϯຊମ
52. サーバーレスによる課題 ・全体像を把握するのが難しい ・適切にエラーハンドリングしないと、何が起こっているかわかりにくい ・ログ管理のベストプラクティスがまだ無い気がする ・マイクロサービス化すると認証、ユーザー基盤とのやりとりが⼤変そう
53. まとめ ・秘訣はたぶん、必要なタイミングで素早く捨てたり作り直したりできること ・当たり前のことを当たり前に泥臭く改善している ・サーバーサイド、インフラで協⼒して進められている
54. ありがとうございました