ECS移設におけるShoryuken導入の経緯と葛藤について / ginzarails_vol34_presentation

銀座Rails#34 登壇資料

Transcript

1. ECS移設におけるShoryuken導入の 経緯と葛藤について 株式会社リンクアンドモチベーション 岸本直樹
2. 自己紹介 氏名： 岸本直樹 出身 経歴 職歴 趣味・特技 愛知県名古屋市 2019年 リンクアンドモチベーション入社 2019年 モチベーションクラウド新機能開発 2020年 SREチーム JOIN 2020年 セキュリティ強化対応 2021年 ECS移設対応 TikTok鑑賞・Apex
3. 今日話すこと ECS移設に伴い、 非同期処理のライブラリを 見直すことになりました。 その過程で起きた 意思決定と課題についてお話します。
4. ECS移設の背景
5. ECS移設の背景
6. ECS移設の背景 ICE BLOCK INK BLOT INTER LINK IDLE LINK 期待: 高 習熟度: 低 | 弱み 期待: 低 習熟度: 低 | やらない 期待: 高 習熟度: 高 | 強み 期待: 低 習熟度: 高 | やらない 2. 変更のリードタイム 1. デプロイ頻度 期待 習熟度 3. 平均修復時間(MTTR) 4. 変更失敗率 14. ソースコードの明確さ 6. インシデントレート Nothing Low Middle High High Middle Low Nothing 7. インシデント再発防止 12. セキュリティリスク 18. 疎結合アーキテクチャ 19. モニタリング 20. セキュリティシフトレフト 8. 生産性に影響する不具合
7. ECS移設の背景 12. セキュリティリスク Before After リリース作業の リードタイム 2時間-3時間 MTTR(切り戻し) 1時間 リリース作業の リードタイム 30分 ※1/6に短縮 MTTR(切り戻し) 10分 ※1/6に短縮 ▼想定アウトカム/先行指標
8. ECS移設の背景 12. セキュリティリスク Before After リリース作業の リードタイム 2時間-3時間 MTTR(切り戻し) 1時間 リリース作業の リードタイム 30分 ※1/6に短縮 MTTR(切り戻し) 10分 ※1/6に短縮 ▼想定アウトカム/先行指標 デプロイ頻度 10回/月 メンテナンス時間 6時間/月 デプロイ頻度 20回/月 ※2倍に増加 メンテナンス時間 0時間 ※メンテフリー ▼想定アウトカム/遅行指標
9. ECS移設における課題 これまでは非同期処理に、 EB用のactive-elastic-jobというgemを利用。 ECS移設に伴い、代替するgemを検討することになる。 https://github.com/active-elastic-job/active-elastic-job
10. Worker要件整理 主な要件 概要 詳細 ジョブ実行の担保 • リトライ処理 • ロストリスク低減 • エラーハンドリング パフォーマンス • 最大同時ジョブ処理数の担保 概要 詳細 コスト • 移行コスト • メンテナンスコスト Must Want
11. 非同期処理要件整理 Workerの比較 Worker Queuing リトライ処理 (must) ロストリスク (must) エラーハンドリング (must) パフォーマンス (want) 移行/運用コスト (want) Sidekiq Redis ◯ △(※) ※Sidekiq Pro では担保される ◯ ◯ △ Resque Redis ☓ ☓ ◯ △ △ Shoryuken AWS SQS ◯ ◯ △(※) ※一部課題あり ◯ ◯ 主にロストリスクとコスト(移行/運用)の観点でShoryukenが選択肢にあがった。
12. Shoryukenとは？
13. Shoryukenとは？ 概要: 「AWS SQS」からジョブ取り出すワーカーを 簡単に作成することができるGem メリット: ・ジョブが失われるリスクがない ・Active Jobが使える デメリット: ・日本では導入事例や記事が少ない https://github.com/ruby-shoryuken/shoryuken
14. Shoryuken導入の課題 1.Logging 2. Testing 3. Resource
15. Shoryuken導入の課題 1.Logging 2. Testing 3. Resource
16. Shoryuken導入の課題 特定アプリケーションにおけるロギング課題 Active Elastic Job Shoryuken pumaプロセスでエラーをキャッチし、 エラーログをSentryに送信。 sqs daemon puma EB
17. Shoryuken導入の課題 特定アプリケーションにおけるロギング課題 Active Elastic Job Shoryuken pumaプロセスでエラーをキャッチし、 エラーログをSentryに送信。 pumaプロセスとは別に、Shoryukenプ ロセスが起動。これまでのエラーハンド リングではエラーログをSentryに送信で きないことが判明。 sqs daemon puma EB ECS エラー 検知実装 puma
18. Shoryuken導入の課題 特定アプリケーションにおけるロギング課題 解決方法：エラー発生時にログを出力するよう独自実装 • 関数 • 各エラーに応じて、エラーログ作成
19. Shoryuken導入の課題 1.Logging 2. Testing 3. Resource
20. Shoryuken導入の課題 非同期処理のテスト課題 ActiveJobを使用可能→ ActiveJob::TestHelperを使用し、実装 Shoryukenを用いてテストコードを書く際、 Shoryuken Shoryuken pollingから処理実行までを自動テストで担保
21. Shoryuken導入の課題 1.Logging 2. Testing 3. Resource
22. Shoryuken導入の課題 リソース効率課題 Shoryukenは1プロセスマルチスレッドベースで設計されているため工夫が必要。
23. Shoryuken導入の課題 リソース効率課題 Shoryukenは1プロセスマルチスレッドベースで設計されているため工夫が必要。 1. コンテナ数をCPUコア数に合わせる 2.プロセス数をCPUコア数に合わせる プロセス プロセス プロセス インスタンス コア コア コア CPU docker docker docker データプレーン層 コア コア コア CPU
24. Shoryuken導入後の結果
25. Shoryuken導入後の結果 ECS移設後Shoryuken含め、安定稼働 🎉 🎉
26. Shoryuken導入後の結果 Shoryukenは使いにくい？ 1. Shoryuken での設定値の共有がイマイチ 2. 100万トランザクションは簡単に突破しそう 3. 個人で開発された gem である
27. Shoryuken導入後の結果
28. Shoryuken導入後の結果 環境変数を利用することで回避した
29. Shoryuken導入後の結果
30. Shoryuken導入後の結果 SQS利用による金額コストは予算内だった
31. Shoryuken導入後の結果
32. Shoryuken導入後の結果 複数の企業で利用実績がある
33. Shoryuken導入後の結果 Shoryukenはオープンソース。 Contributorとして、開発で必要な時は自ら修正できる。
34. 最後に We Are Hiring!! https://www.wantedly.com/companies/lmi