Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

527e2af04bd5b212b479840016274cdb?s=47 Yutaro Sugai
November 21, 2017

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

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

527e2af04bd5b212b479840016274cdb?s=128

Yutaro Sugai

November 21, 2017
Tweet

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に完全移⾏

  19. None
  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. ありがとうございました

  55. None