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

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

Transcript

1. Eightがサーバーサイド/インフラの
   メンテナンス性向上のために実現
   してきたこと
   

   View Slide

2. # sansan_gmopepabo
   ຊ೔ͷϋογϡλά
   

   View Slide

3. エンジニアの王国から来ました
   https://slack.com/intl/ja-jp/customer-stories/sansan
   

   View Slide

4. 菅井祐太朗 (@hokkai7go)
   Sansan株式会社 Eight事業部
   インフラエンジニア
   • Chef実践⼊⾨
   • Railsエンジニアの横にいる歴 5年
   • サーバーをレス化する際の権限まわ
   りをあれこれすることが増えた
   • ⼀般社団法⼈LOCAL 理事
   

   View Slide

5. ビジネスの出会いを資産に変え、
   働き⽅を⾰新する
   Mission
   

   View Slide

6. Your business network
   

   View Slide

7. 本発表について
   Eightがサーバーサイド/インフラのメンテナンス性向上のために実現してきたこと
   について事業部全体や、チーム内での取り組みについて紹介します
   

   View Slide

8. 秘訣
   7
   

   View Slide

9. 必要なタイミングで
   捨てたり作り直したりできること
   なのかなと
   

   View Slide

10. アジェンダ
    9
    

    View Slide

11. チーム体制
    監視システム
    リリース
    アプリケーションログの収集、分析
    サーバーレス化
    

    View Slide

12. チーム体制
    11
    

    View Slide

13. 7チーム * 4~5名くらい
    合計 35名程度のエンジニア
    

    View Slide

14. バックエンド開発 5チーム
    モバイル(iOS, Android) 1チーム
    基盤チーム 1チーム ← ココ
    

    View Slide

15. 基盤チーム
    Railsエンジニア * 3
    インフラエンジニア * 2
    

    View Slide

16. チームがフォーカスしていること:
    インフラ、セキュリティ、パフォーマンス、
    開発者全体の⽣産性向上
    

    View Slide

17. 監視システム
    16
    

    View Slide

18. 2017年1⽉
    Nagios→Mackerelに完全移⾏
    

    View Slide

19. View Slide

20. Mackerelでやれることはだいたいやってる
    が、独⾃でやっているものもある
    

    View Slide

21. AWS Integrationで取れないメトリクスの取得、監視
    粒度の細かいリソースに関するメトリクス⾃動取得
    →監視に関わるLambdaが4つほど
    

    View Slide

22. AWS Integrationで取れないメトリクスの取得、監視
    Auroraのinnodb status
    DynamoDBのキャパシティ消費率計算、監視
    SESのbounse率計算、監視
    

    View Slide

23. 例: DynamoDBのキャパシティ消費率計算、監視
    CloudWatch APIを叩き、Read/Write
    Capacityの使⽤率を計算
    Mackerelに consumed_[read/write]_ratio
    としてメトリクスを投稿し、監視を設定
    

    View Slide

24. 粒度の細かいリソースに関するメトリクス⾃動取得
    DynamoDB Stream
    Kinesis StreamのShard
    →増えたときにモニタリング追加が漏れそうなもの
    CloudWatch APIで取得、Mackerelに投稿
    

    View Slide

25. Lambdaの他にもIAM権限はTerraformで管理し
    インフラもコードで管理し、⽇々PR出してます
    

    View Slide

26. リリース
    25
    

    View Slide

27. これまで、リリースについては
    いくつかの問題点有り
    

    View Slide

28. 問題点
    デプロイを複数に分けて⾏う必要があった
    リリース⽅法が⼀本化されていない部分があった
    ⼿作業が多かった
    リリースにかかる時間が⻑かった(ひどいと2~3時間)
    

    View Slide

29. 対策として⾏ったこと
    

    View Slide

30. 対策の動き
    リリース所要時間計測
    リリース改善の機運の⾼まり
    リリース⽅法の⼀本化
    リリースブランチPR⾃動作成botの導⼊
    デプロイとassets:precompileの分離
    Golden Image(AMI)作成⾃動化
    Autoscalingの導⼊
    Blue/Green Deploymentの導⼊
    設定ファイルの簡略化
    

    View Slide

31. 対策の動き
    リリース所要時間計測
    リリース改善の機運の⾼まり
    リリース⽅法の⼀本化
    リリースブランチPR⾃動作成botの導⼊
    デプロイとassets:precompileの分離
    Golden Image(AMI)作成⾃動化
    Autoscalingの導⼊
    Blue/Green Deploymentの導⼊
    設定ファイルの簡略化
    

    View Slide

32. リリースブランチPR⾃動作成botの導⼊
    リリースは⽕⽊の昼頃
    リリースブランチPR作成をLambdaが⾃動的にやっている
    →リリース担当の⼿間を削減
    Slackを⾒られれば、その⽇のリリースPRがわかる
    

    View Slide

33. デプロイとassets:precompileの分離
    これまでデプロイ時にWebサーバ全台で assets:precompileを⾏っていた
    ↓
    デプロイサーバでのデプロイ時にS3へアップロード、CloudFrontで配信
    

    View Slide

34. Golden Image(AMI)作成⾃動化
    GitHubでmasterブランチをマージ
    Applicationデプロイ済み(全部⼊り)のイメージが⾃動的に出来上がる
    Slackにリリースコマンドが提⽰される
    →次の⼀步は、⾃動でリリースかな？
    

    View Slide

35. Golden Image(AMI)作成⾃動化
    

    View Slide

36. Blue/Green Deploymentの導⼊
    おなじみのMartin Fowler⽒が提唱した概念
    ・Golden Image作成⾃動化
    ・Autoscaling導⼊
    ・アプリケーションログ収集(後述)
    が整備されたことで準備が整った
    https://martinfowler.com/bliki/BlueGreenDeployment.html
    

    View Slide

37. リリースの改善についてのまとめ
    ・⼿作業をほぼ撲滅できた
    ・リリース内容に左右されてリリース時間が延びることはなくなった
    ・所要時間のうち待ち時間の割合がかなり増えた
    ・リリース担当から、リリース作業がかなり楽になったとの喜びの声
    

    View Slide

38. アプリケーションログ収集、分析
    37
    

    View Slide

39. アプリケーションログも
    いくつか課題があった
    

    View Slide

40. アプリケーションログに関する課題
    ・ログレベルがまちまち
    ・不要なログが⼤量に出ていた
    ・分析⼿段も⽤意できてなかったため、調査のコストがとても⾼い
    ・サーバへログインしなくてはならない状況
    ・セキュリティ的懸念
    ・運⽤事故を⽣む懸念
    

    View Slide

41. アプリケーションログに関してやったこと
    ・容量、⾏数の計測
    ・削減⽬標を決めた
    ・不要そうなログをざっくりまとめた
    ・ログレベルの整理
    ・⼈海戦術で不要ログ出⼒を⽌めた
    ・fluentdで収集、Elasticsearch→Kibanaで可視化、分析可能に
    

    View Slide

42. サーバーレス化
    41
    

    View Slide

43. https://goo.gl/1dnUeH
    

    View Slide

44. https://goo.gl/2U8i58
    

    View Slide

45. リアルタイムなリコメンデーション
    をサーバーレスで実現した
    

    View Slide

46. リコメンデーションシステムの概略図
    

    View Slide

47. フィードのOGP画像リサイズ&キャッシュ
    をサーバーレスで実現した
    

    View Slide

48. OGP画像リサイズ&キャッシュシステムの概略図
    

    View Slide

49. Feed OGPը૾
    ϦαΠζ&Ωϟογϡ
    Ϧίϝϯσʔγϣϯ
    ΞϓϦέʔγϣϯຊମ
    

    View Slide

50. サーバーレスの適⽤範囲
    ・リアルタイムリコメンデーション
    ・フィードのOGP画像のリサイズ&キャッシュ機構
    ・監視システムの⼀部
    →イベントドリブンな処理で今後も適⽤範囲が広がるだろう
    システムを分割することでソースコード、リリースなどの依存性を少なくし
    ある程度まではメンテナンス性向上につながる
    

    View Slide

51. Feed OGPը૾
    ϦαΠζ&Ωϟογϡ
    Ϧίϝϯσʔγϣϯ
    ΞϓϦέʔγϣϯຊମ
    

    View Slide

52. サーバーレスによる課題
    ・全体像を把握するのが難しい
    ・適切にエラーハンドリングしないと、何が起こっているかわかりにくい
    ・ログ管理のベストプラクティスがまだ無い気がする
    ・マイクロサービス化すると認証、ユーザー基盤とのやりとりが⼤変そう
    

    View Slide

53. まとめ
    ・秘訣はたぶん、必要なタイミングで素早く捨てたり作り直したりできること
    ・当たり前のことを当たり前に泥臭く改善している
    ・サーバーサイド、インフラで協⼒して進められている
    

    View Slide

54. ありがとうございました
    

    View Slide

55. View Slide