$30 off During Our Annual Pro Sale. View Details »

WeblioはSREチームの0→1フェーズにどのようにAWSを取り入れているのか

paprika-mah
November 09, 2021

 WeblioはSREチームの0→1フェーズにどのようにAWSを取り入れているのか

JAWS-UG SRE支部 #1に登壇しました。
https://jawsug-sre.connpass.com/event/227752/

paprika-mah

November 09, 2021
Tweet

More Decks by paprika-mah

Other Decks in Technology

Transcript

  1. はSREチームの0→1フェーズに 2021/11/09 paprika-mah どのようにAWSを取り入れているのか

  2. Who am I ・Name - paprika-mah - パプリカって呼んで下さい ・Career -

    2021年4月〜 - GRASグループ株式会社 - SRE Engineer - 2014年4月〜2020年3月 - ユーザ系SIer (DC, ISP, MSP, SI) - AWS Solution Architect ・Location - portfolio: paprika-mah.net - Twitter: @MahPaprika - GitHub: paprika-mah ・My Favorite AWS services - AWS Lambda - Amazon Connect - Amazon Polly - Amazon Lex
  3. Weblioを支える技術 • クラウド ◦ AWS ◦ IDCF - Private Cloud

    - • 仮想化 / コンテナ ◦ VMware ◦ (ECS + Fargate) • 開発言語 ◦ React / Node.js; Express ◦ Vue / Java; Spring boot • 構成管理 ◦ Terraform • CI/CD ◦ GitHub Actions ◦ (Terraform Cloud) • Monitoring ◦ Cloud Watch ◦ Zabbix ◦ (Datadog)
  4. SRE ジャーニー - Prologue -

  5. WeblioのSREジャーニーはどこからスタートしたのでしょう??

  6. 私が入社(今年4月)したとき・・・・・・・・・

  7. 開発チームは以下のような状況であった。 • AppチームとInfraチームのサイロ化 • ロストテクノロジーと化した仕様 • 管轄が曖昧なCMS • NoOps(※意味深) •

    巨大でモノリシックなシステムで、複雑化しがちなプロダクト Weblioは2005年に創業したADSLの時代から続く会社なので、 どうしても負債というものは避けられませんね・・・・。
  8. AWSについては下記の状況であった・・・・・・・・。 • 全てのサーバーが稼働率100% • 全てが無期限保持のCloudWatchLogs • CPUバーストして、1年近く経過しているjunior software engineerのオンボーディング 用EC2

    • 利用していないはずのリージョンに謎のリソースが?! • プロダクト、サービスありきで、標準化されてないメトリクス・ロギング指標 • もう不要なS3バケットやAMIバックアップなどのリソース AWS利用開始したのが、2010年11月からのため、これまた歴史が長く。。。 Trusted Advisor初見、月額料金節約の可能性に$3500と表示されていました。
  9. リスナーの皆様の中に、今似たような状態であるユーザさ んはいらっしゃいますか🤔??

  10. ひょっとしたら、今日のこれまでのみなさんの発表でSREを 始めるには敷居が高く感じてしまったのかもしれません😭 (というか、私がそうです)

  11. 今から僕がSREを始める敷居を下げに行きますの で、ご安心下さい!!!!!!!!!!!!!

  12. Agenda: 【Weblio SREジャーニー】 ①最初にやったこと ②SREをするための準備 ③SREを取り入れよう ④SREの0=>1フェーズが終わるとき

  13. ①最初にやったこと

  14. どこから始めれば良い・・・・・・・🤔??

  15. 時間もリソースも限られてる中で、何を優先する?

  16. SREのプラクティスは勿論、まずは運用が出来る よう整えていかなければ・・・

  17. 最優先すべきはセキュリティですね・・

  18. 開発チームは以下のような状況であった。 • AppチームとInfraチームのサイロ化 • ロストテクノロジーと化した仕様 • 管轄が曖昧なCMS • NoOps(※意味深) •

    巨大でモノリシックなシステムで、複雑化しがちなプロダクト Weblioは2005年に創業したADSLの時代から続く会社なので、 どうしても負債というものは避けられませんね・・・・。
  19. None
  20. WAFを入れましょう><

  21. 慣れている製品を使いたい方、MarketPlaceを探してみると提供されているかも?! マネージドなWAFサービス(v1 / v2)

  22. サイトの信頼性を担保するSREは、ユーザに安心してサービスを使ってもらわないといけません WAFでセキュリティを確保することが一番最初の一歩だと考えてます。

  23. Weblio英語辞書で実際に発生したケーススタディ

  24. Weblio英語辞書で実際に発生したケーススタディ

  25. Weblio英語辞書で実際に発生したケーススタディ

  26. チューニングしていきましょう!!!!!!

  27. 1度チューニングしたら終わりではありません🙃

  28. WAFは定期的なチューニングを👍

  29. 何故定期的にWAFのチューニングが必要なのか?? その日はある日突然やってくる・・・・・・・・・・・

  30. 突然やってくるエラー • 開発チームに聞くも、機能リリースはしてない • インフラ・情シスチームに聞くも、インフラの構成変更も行っていない • メトリクス・パフォーマンス観測した結果、外部攻撃や内部トラブルなど異常は無さそう ? ◦ 何もしてないのに一部壊れた・・・・

    🤔?! • 何よりも現象再現しない・・・・。 ◦ みんな問題なく使えてるみたいで、一部のユーザさんにトラブルが ?? • 確かにFortiweb見ると、いくらかエラーが起きてるけど・・・・。
  31. 結果: 3rdParty Cookieに算術演算記号が含まれるケースが発生し、偽陽性が起きていた。

  32. 暫定的に当該クッキーのホワイトリスト登録で対応しましたが、 このとき日付を跨ぐサービスダウンを発生してしまいユーザの影響は大きかったです。

  33. None
  34. WAF is 大切

  35. WAF以外にもセキュリティの見直しポイントは多いです!! • アカウントのセキュリティ • IAMのセキュリティ ◦ クラウド破産を回避するためにはgit-secretsなどのOSS導入も👍 • 各種サーバーのセキュリティ 結論:

    セキュリティの見直しを🙌
  36. そして、モニタリングをしよう!!

  37. CloudWatchが大活躍!! 他社の大規模な統合型監視SaaSも魅力的ですが、 近年、CloudWatchも機能拡充がすさまじく感じてます!!

  38. CloudWatchでAPM関連が近年ますます便利に・・・・っ !!

  39. ダッシュボードはIAM不要でアクセスも可能に・・・。 毎日のデイリースクラムで定点観測会を実施中

  40. 駆け足にはなりますが、簡単にFirst Step; 最初にやらなければならないと思うこ と話しました。 • セキュリティの確保 • モニタリングの開始 詳しくはWell-Architected Frameworkを見れば、最適化に沿った形でAWSを利

    用でき、インフラ面の改善に繋がり、SREのプラクティスの実践土台が出来上がる のかなと思います。 ロストテクノロジーや塩漬けとなった運用業務については、AWS managed serviceへのマイグレーションをすれば、きっとあなたの助けになるはずです!! 例: Jenkins => AWS Code series 例: FortiWeb => AWS WAF
  41. ②SREをするための準備 ここまでで5分経過なら時間配分良い感じ👍

  42. SREにとって大切な要素とは?

  43. サービス信頼性ヒエラルキー まず最初に可観測性があって、システムを観察出来るこ と。 インシデントがあれば対応して、再発防止を努めなけれ ばならず、止まらないよう仕掛けが必要。 つまり、インシデント発生時に回復力や、障害時の影響を 留めるべく疎結合な作りが大切になる。 リリースなどのデリバリー戦略やキャパシティプランニン グなどの管理力が求められる。

  44. クラウドネイティブに行こう モノリスのままでもSREは出来るけどやっぱり移行したい!!

  45. SREチームは、12FactorAppの原則に沿ったリファクタリングをしてます。 • ここも勿論AWSファーストな技術選定 ◦ ECS + Fargate / Lambdaなどの構成でプロトタイプを作成中 ▪

    IDCFプラクラ側もいずれはk8s Amazon ECS Anywhereを導入したい • 誰かお力お貸し下さい。興味ある方は是非🙌 所感; (SREのアプローチに向けて最適化出来る以外にも、複雑化して各サービスが絡み合うプロダクトをリ ファクタしていくと、プロダクトの在り方と一緒に自然とエンジニアリング組織も変わっていくのかなとい う印象(conway's lawをひしひしと感じた))
  46. アプリの作りの話なんかも出てくると・・・まあ途方もな い話で・・・・。

  47. SREへの道のりは長い感じがしますね・・・😭

  48. すぐ出来るアプローチだってあります💡

  49. ③SREを取り入れよう

  50. すぐに出来るアプローチ • パフォーマンス定点観測会 ◦ デイリースクラムで実施 ▪ CloudWatchのダッシュボードを活用 • ポストモーテム読書会 ◦

    ヒヤリハット発生時や新規参画者のジョインなど、不定期開催 ▪ (※ポストモーテムは障害発生時に原則行ってます ) • ポストモーテムはテンプレート化 • Toil撲滅 ◦ 件のYahoo知恵袋とCookieのチューニングの件(ホワイトリストの脱却) • 可観測性の確保 ◦ 0=>1のフェーズでは、メトリクスは多ければ多いほど良いのかと。 • オンコール対応 ◦ 緊急時の当番や対応表の見直し
  51. ④SREの0=>1フェーズが終わるとき

  52. • SLI/SLO ◦ エラーバジェット運用 • チームの本格ビルド ◦ ミッションステートメント ▪ Vison

    ▪ Misson ▪ Values ◦ オンボーディング計画 ◦ アラートハンドリング ◦ 可観測性の確保 ◦ チームの在り方 ▪ 他部署とのOrganization 定めるべき事項多し(現状のWeblioは仮ですら決まってないです) ・・・Weblio SREが1になるにはあともう少し?!
  53. 最後にWeblioでSREチーム発足の経緯を話すと・・・ 開発者が機能の開発に集中出来ないという課題が大きな要因 • 障害に対応出来る人がいない ◦ 障害の原因が分からなくて対応出来ないのではなく、調査するには環境不充分 ▪ ステージングでは構成が違う為、現象再現出来ない。 ▪ ログの不充実

    ▪ メトリクス・モニタリングの不充実
  54. SREをやってみてどうだったかというと・・・・・・ いくらかの成果があった。 • Developer Productivityの向上 ◦ 機能の開発に集中して、またDevOpsスキームの中で、働く文化も根付いた。 • Site Reliabilityの向上

    ◦ 運用業務による障害を未然に防ぐためのアプローチ・障害時の復旧などに従事 (SREらしく、データドリブンで示せないのが、悲しいですが )
  55. SREをやってみてどうだったかというと・・・・・・ 効果を感じた分、凄く大変なこともあった。 それは、他人は変えられない(ことが多い)のに、組織や文化を変えなきゃいけない。 SRE への道のりには、技術的な面からの課題と人間的な面 (文化やプロセスなど)からの課題がいく つも折り重なっています。 エンジニアリングから経営陣まで、 SRE の実装に関与するすべての関係者は、変化には時間と労

    力がかかること、そして短期的にはリソースが必要であることを認識する必要があります。 手ごわい挑戦のように思えるかもしれませんが、 SRE の目標は、困難な問題を克服してより良い明 日を築くことです。
  56. SREをやってみてどうだったかというと・・・・・・ 大きなやりがいがありました。 • Weblioの月間PV数は2.4億です。 ◦ 1行のログの先には1人のユーザが居ます。 ▪ 述べ2.4億のユーザが信頼してサービスを使ってもらうために躍起になれる このSREジャーニーで学んだ大きな成果です。

  57. WE ARE HIRING!! AWSファーストにSREをやりたい方は是非、私とカジュアル面談しましょう !! ご清聴ありがとうございました