技術的負債になりかけていた機能をリアーキテクティングしたらめちゃくちゃ改善した話 / A story that improved a lot when re-architecting a function that was about to become technical debt

2023/06/22　AWS DEV DAY 2023　TOKYO
技術的負債になりかけていた機能をリアーキテクティングしたらめちゃくちゃ改善した話
https://aws.amazon.com/jp/events/devday/japan/

ソフトウェアエンジニア
鈴木 健太郎

Transcript

1. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. J U N E 2 2 , 2 0 2 3
2. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 技術的負債になりかけていた機能を リアーキテクティングしたら めちゃくちゃ改善した話 鈴木 健太郎 (@szk3) C - 3 ソフトウェアエンジニア 株式会社カミナシ
3. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 鈴木 健太郎 / Kentaro SUZUKI @szk3 株式会社カミナシ エンジニアリング本部 Harami Enginieering 第２ユニット ソフトウェアエンジニア 自己紹介
4. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 想定受講者 • バッチ処理のリプレイスや改善を検討しているアーキテクト、 ソフトウェアエンジニア ゴール • 紹介事例を通じて、設計の選択肢が広がること 本セッションは
5. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. • AWS CodeBuild • AWS Batch • AWS Fargate • AWS AppConfig 登場する主なAWSのソリューション／サービス
6. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 話すこと • 技術的負債になりかけていた機能のリアーキテクティング事例紹介 • AWS Batch を使ったリアーキテクティング • AWS AppConfig を使った段階的ロールアウト 話さないこと • 各AWSのソリューション／サービスの具体的な説明や詳細な使い方 話すこと、話さないこと
7. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. • 旧アーキテクチャと、抱えていた課題 • 新アーキテクチャと、解決できた課題 • 安全な段階的ロールアウトを実現する • AWS AppConfig の知見共有 • まとめ アジェンダ
8. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 旧アーキテクチャと、抱えていた課題
9. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. お客様は業務上発生する紙への記録（点検, 食品衛生管理 など）を、 タブレットやスマートフォンで入力することができます （ ※これらは、カミナシが提供する機能のひとつです ） 前提 カミナシの提供するサービス
10. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Excel変換 • カミナシに保存された帳票記録をExcel形式に変換して出力する機能 • 定期的に繰り返される バッチ処理による変換出力 リアーキテクティングの対象となった機能 帳票記録DB xlsx
11. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 利用状況の変化 • 設計当初と課題になりつつあった時期を比較すると、 記録された帳票の数は約4倍ほどに増加していた • 利用者の増加とともに、設計当初のシステムアーキテクチャが 技術的負債となっていた リアーキテクティングの背景
12. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. goroutine (1..n) 旧システムアーキテクチャ AWS Cloud AWS CodeBuild Amazon EventBridge Amazon Elastic Container Registry (Amazon ECR) Amazon Simple Storage Service (Amazon S3) Container R / W Write xlsx Triger Image pull Docker run 1 2 3 4 Create xlsx file Amazon Aurora
13. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. １．バッチ処理のスループットを上げにくい ２．AWSリソースの利用コストが無駄にかかる ３．バッチ処理が失敗するとスクラムに影響が大きい 旧システムアーキテクチャ課題
14. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. バッチ処理の 完了時間や処理量が見積もりにくい • 1回のバッチで処理するデータ量は利用状況により変動する • 特定のタイミング(月末/月初など)で処理時間が長くなる 1. バッチ処理のスループットを上げにくい(1/3)
15. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. バッチ処理の実行環境である AWS CodeBuild がタイムアウトする という問題が発生 • AWS CodeBuild のタイムアウトを段階的に伸ばす暫定対応を実施 1時間 → 3時間 → 8時間（※AWS CodeBuild の仕様上の上限値） 1. バッチ処理のスループットを上げにくい(2/3)
16. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. また、タイムアウトを上限まで伸ばしたタイミングで、 AWS CodeBuild の 割当リソース設定も限界までスケールアップ • 本対応の目的は、”少ない工数”で障害になりにくい状態を作ること • バッチ処理に長い時間がかかる事実は変わらない • この時点で、スケールアップの余地はなくなった • バッチ処理の改修や、インフラのスケールアウトなしに スループットを上げにくい状態になっていた 1. バッチ処理のスループットを上げにくい(3/3)
17. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 予測が難しい負荷を考慮し、上限までスケールアップした結果 • AWS CodeBuild の 利用コストは約4倍になった ※ ほとんどのバッチ処理で、これほどのリソースは不要 2. AWSリソースの利用コストが無駄にかかる
18. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. バッチ処理は1プロセスで動くため、プロセスごとエラーになると 全ての変換処理に対して、リカバリ処理を行う必要があった 3. バッチ処理が失敗するとスクラムに影響が大きい(1/2) goroutine (1..n) job job job job xlsx Wait Wait container Timeout at AWS CodeBuild Recovery targets process kill
19. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 3. バッチ処理が失敗するとスクラムに影響が大きい(2/2) リカバリ担当者による手動オペレーションが必要 • 当時のシステムはクラウド側でリトライすることを前提とした コードやシステムアーキテクチャになっていなかった ・ エンジニアが、ローカル環境でソースコードを書き換えて、 ハイコンテキストなリカバリ処理を実行 ・ 経験豊富なエンジニア1-2人で1営業日程度の時間を要した
20. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. １．バッチ処理のスループットを上げにくい ２．AWSリソースの利用コストが無駄にかかる ３．バッチ処理が失敗するとスクラムに影響が大きい 旧システムアーキテクチャ課題 (再掲)
21. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 新アーキテクチャと、解決できた課題
22. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Design Doc を記述 し、関係者の認識をあわせる • これまでの対応状況と現状の整理 • リアーキテクティングのアウトカムの定義 • 課題を解決するためのアーキテクチャ設計案 リアーキテクティングの事前準備
23. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. リアーキテクティングの結果、どんな状態になりたいのかを言語化 • 変換処理が集中する月初の目標処理時間を1時間以内に • 2-3 年後を想定した変換処理量を問題なく処理できる リアーキテクティングのアウトカムを定める
24. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 新システムアーキテクチャ AWS Cloud Amazon EventBridge Amazon Simple Storage Service (Amazon S3) xlsx Triger Find conversion targets Job Submit 1 2 3 4 AWS Batch AWS Fargate Amazon Elastic Container Service (Amazon ECS) Container AWS Fargate Amazon Elastic Container Service (Amazon ECS) Job Scheduling 5 6 Find export data Create xlsx file Amazon Aurora
25. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Batch を中心に再構築 し、スケーラビリティを確保 • アプリケーションを責務で分離 • リカバリ処理の効率化 • AWS Batch と AWS Fargate で全体的なコストの最適化 新システムアーキテクチャのポイント
26. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS CodeBuild のコンピュートリソース上で実行していたコンテナを AWS Batch on AWS Fargate で実行 するように再構築 非同期処理にAWS Batchを採用、変換処理のスケールアウトを実現 AWS Batch を中心に再構築 AWS CodeBuild AWS Fargate AWS Batch Docker Container before after
27. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. バッチ処理をスケールアウトさせることができ、運用負荷が低い • スケーラブルなキューイング機能 • コスト最適化されたスケーリング性能 • AWS Batch 自体の利用は無料 (※ ジョブを実行するコンピュートリソースなどは有料です） • リトライの容易さ AWS Batch を選んだ理由
28. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. • 1つの変換処理で最大20分程度かかるケースを観測していた為、 AWS Lambda は最大実行時間の制限により選択肢から除外 （ ※現時点での最大実行時間は15min ） AWS Fargate を選んだ理由
29. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Batch への Job Submit の部分は、AWS Lambda を用いる設計 も検討したが、現状のメンバーで運用していくことを見据えながら、 変えすぎない部分について議論 し、チームで合意した 優先させたこと • 既存の技術スタックに合わせる • 既存のデプロイフローの流れに寄り添う AWS Fargate 以外の設計案
30. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリケーションを "変換処理のEnqueue" と "変換処理" に分割 • 変換処理を非同期的に処理し、スケールアウトできるようにする • 変換処理を独立して処理し、失敗時の影響範囲を限定的にする アプリケーションの分割
31. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 責務の分割 AWS Cloud xlsx Triger Find conversion targets Job Submit 1 2 3 4 AWS Batch AWS Fargate Container AWS Fargate Job Scheduling 5 6 Find export data Create xlsx file 変換処理のEnqueue 変換処理 Amazon Aurora
32. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 非同期処理とスケールアウトの実現 AWS Cloud xlsx Triger Find conversion targets Job Submit 1 2 3 4 AWS Batch AWS Fargate Container AWS Fargate Job Scheduling 5 6 Find export data Create xlsx file 非同期処理、変換処理のスケールアウト Amazon Aurora
33. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 影響範囲の限定化 AWS Cloud xlsx Triger Find conversion targets Job Submit 1 2 3 4 AWS Batch AWS Fargate Container AWS Fargate Job Scheduling 5 Find export data 影響範囲の限定化 Amazon Aurora
34. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. リカバリ手法を再設計し、AWS Batch で再試行を自動化 • AWS Batch で 3回まで再試行を実施 • 再試行で失敗であれば、ジョブをクローンしリトライする リカバリの効率化 https://docs.aws.amazon.com/ja_jp/batch/latest/userguide/job_retries.html
35. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 利用するリソース利用料の最適化 • AWS CodeBuild の 利用コストを約90%程度削減 コストの最適化
36. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 通知の導入 • AWS Chatbot を使ったSlackへの連携 処理失敗時の検知の仕組み ※画像は一部マスクしています
37. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Batch と AWS Fargate でリアーキテクティングした結果 １．バッチ処理のスループットを上げにくい ▶ スケールアウトできる仕組みの実現 新システムアーキテクチャ まとめ(1/3)
38. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Batch と AWS Fargate でリアーキテクティングした結果 ２．AWSリソースの利用コストが無駄にかかる ▶ AWSリソースの利用コストを約90%程度削減 (※ ほぼAWS CodeBuild のコストだった) 新システムアーキテクチャ まとめ(2/3)
39. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Batch と AWS Fargate でリアーキテクティングした結果 ３．バッチ処理が失敗するとスクラムに影響が大きい ▶ 監視の仕組みを追加 ▶ リトライ処理の効率化 新システムアーキテクチャ まとめ(3/3)
40. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 変換処理が集中する月初の目標処理時間を1時間以内に ▶ 先月比較で2時間7分(127分) → 29分 ＝ 処理時間は 約1/4 に (※ 移行時の数値 ) 2-3 年後を想定した変換処理量を問題なく処理できる ▶ 今のスループットから、十分に処理できると判断 アウトカムの達成度
41. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 実装しなかったこと • 変換処理失敗時のチケット管理システムへの連携 • 処理の重み付けのような、既存にはない機能 やらなかったこと
42. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 安全に段階的ロールアウトを実現する
43. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 新旧システムを併用しながら、機能フラグ(Feature Flags)を用いて 段階的なロールアウトを実施した • おそよ1ヶ月程度の併用期間 • カスタマーサポート(CS)チームがサポートしやすい移行計画 安全に段階的ロールアウトを実現する
44. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 本番ワークロードにおいて新システムがもたらす不確実性を排除する • ロールバックのしやすさを重視 • リリースとカットオーバーを分離し、ビッグバンリリースを避ける • 想定されるリスクの段階的検証 機能フラグを用いる背景
45. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. • 環境変数 • コンテナに反映するのに Amazon ECS タスク定義 の修正が必要 • AWS Systems Manager Parameter Store • 必要最低限で良い (設計当初の第一候補) 機能フラグの実装案(1/3)
46. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. • Amazon DynamoDB テーブル • データ構造を柔軟に管理できるがゆえに、迷いを生む可能性 • Amazon CloudWatch Evidently • Validation name が 大量になるようなケースへの適用は難しい (※ 設計当時の考慮から漏れてたので、後から考えた結果このように判断) 機能フラグの実装案(2/3)
47. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. • AWS AppConfig 機能フラグ • 段階的ロールアウトの移行粒度を表現しやすかった • とはいえ、AWS Systems Manager Parameter Store でも 実装は可能 機能フラグの実装案(3/3)
48. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 機能フラグのマネージドサービスとして、知見を貯めたかった • ソースコードのデプロイが不要 • フラグの制約やバリデーターなどのガードレール (※) • CloudWatch アラーム をトリガーにフラグの自動ロールバック (※) (※ これらは選んだ理由としてはあげていますが、今回のタイミングでは使えておりません) AWS AppConfig を選んだ理由
49. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. • 仮に何かしらのトラブルが発生した際に、カスタマーサポート／ サービスチームと連携し、迅速に対応したかった • ロールアウトの粒度は、帳票記録の利用頻度や想定される出力処理 の量などを可能な限り調査し、お客様を5つのグループに分類して、 グループ単位でロールアウトしていった 段階的ロールアウトの計画 利用頻度が低い 利用頻度が高い Group 5 Group 4 Group 3 Group 2 Group 1
50. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. not exists AWS AppConfig 機能フラグ に数値配列を選択し移行対象のIDを設定 • 両システムから最新の機能フラグを取得し、移行対象のIDを処理 機能フラグを使った段階的ロールアウトの設計 1 AWS Cloud AWS AppConfig Container Previous system Current system AWS Fargate exists 1, 2 1, 2, 3, 4 1, 2, 3, .. n 1, 2, 3, .. 7 v1 v2 v3 v4 latest
51. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 新旧環境の併用における、Amazon Aurora への負荷のリスク • 旧システムと新システムは排他制御で、処理の総和は変化しない • 新システムはスケールアウトするので、瞬間的に負荷が高くなる リスクが想定されていた 想定されるリスクの段階的検証 AWS Cloud Container Previous system Current system AWS Fargate Amazon Aurora
52. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Batch の 最大vCPUとAWS Fargate の vCPU から ジョブの並列度をコントロールできることがわかった • 例）最大vCPU 40 / 2.0 vCPU = 20並列 • これで、新システムの並列度をコントロールできる ようになった ※ 公式Docではコンピュート環境にFargateを使うときの "無効な" パラメータの一覧は存在するが、 その中に maxvCpus が "ないので使える" と判断した。実際の挙動を元に問い合わせを行い maxvCpus が使えると確定 スケールアウトをコントロールする https://docs.aws.amazon.com/batch/latest/userguide/fargate.html#fargate-compute-environments
53. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 無事に全ての移行が完了 • 特に 大きなトラブルなし • 段階的ロールアウト中に、失敗時のRunbookが有効性を確認 • AppConfig 関連のリソースやソースコードは削除 • 旧システムも経過観察後にシャットダウン 安全に段階的ロールアウトを実現する - まとめ
54. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS AppConfig の知見共有
55. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Terraform 経由で想定したリソースが作成できなかった • 当時の AWS Provider が古く、機能フラグではなく 自由フォーマットのリソースとして作成されてしまった ▶ AWS Provider の verupで解決 (v3.57.0 -> v4.46.0) AWS AppConfig 関連のトラブル(1/3)
56. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Terraform で差分が出続ける • aws_appconfig_hosted_configuration_version の content の `_updatedAt` が apply の度に変わる ▶ content を ignore changes することで回避 AWS AppConfig 関連のトラブル(2/3)
57. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 本番環境の AWS AppConfig リソースが作られる前に、旧システムの 改修コードがデプロイされてしまった • 前述のトラブルを解消するために開発環境で検証が継続中だった • IaCのデプロイフローとアプリケーションのデプロイフローが別 ▶ 関係各位を巻き込み、リカバリ対応を行った AWS AppConfig 関連のトラブル(3/3)
58. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 最新の設定をもってくる GetLatestConfiguration API は有料です • バッチ処理のくらいの起動頻度であれば許容できるコストも、 大量のトラフィックを受けるWebサイトなどでリクエスト単位で コールすると、コストが想定以上になる可能性があります AWS AppConfig GetLatestConfiguration API https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_appconfigdata_GetLatestConfiguration.html
59. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS AppConfig のサイドカーコンテナ が公開されている • 内部的に設定をキャッシュしてくれてローカルのHTTPリクエストを 通じて機能フラグを取得してくれて、実装もシンプルになる AWS AppConfig の サイドカーコンテナ https://gallery.ecr.aws/aws-appconfig/aws-appconfig-agent
60. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ
61. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Batch と AWS Fargate で システムアーキテクチャを刷新 し、 AWS AppConfig を使って 段階的なロールアウト を実現 バッチ処理のリアーキテクティング AWS AppConfig AWS Batch AWS Fargate
62. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. スケールアウトの上限をコントロール ▶ AWS Batch のコンピューティングリソースで試算可能 非同期処理により、スループットの向上 ▶ 繁忙時間帯の処理時間は4分の1以下 コントロールしやすいスケールアウト
63. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 変換処理の信頼性を向上 ▶ アプリの責務を分割し、エラー時の影響範囲を限定的に ハイコンテキストで時間がかかるリトライ作業からの脱却 ▶ AWS Batch の Job を再実行するだけに リカバリ負荷の低減
64. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS CodeBuild から AWS Batch へシフト ▶ AWS CodeBuild リソース利用量を 約90%削減 ▶ AWS Batch 自体の利用は無料 AWSサービス／リソースの利用コストを最適化
65. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS AppConfig の 機能フラグ (Feature Flags) を用いて、 本番ワークロードへの段階的ロールアウトを実現 ▶ 影響範囲を最小化 ▶ ロールバックしやすい状態の構築 機能フラグ を用いた段階的ロールアウト
66. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. アーキテクチャやコンテキストが完全に同じものは存在しない。 だからこそ、最適なアーキテクチャを検討しつづける 必要がある。 故に当時の設計を安易に否定せず、受け入れてちょっとだけ改善し 今のメンバーで一緒に前に進んでいくことが大切。 最後に(1/2)
67. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. ベストプラクティスが正解である保証はどこにもありません。 選んだアーキテクチャを正解にしていくという姿勢が大事。 （最大限考慮してやってダメなら、またやり直せばいい） 最後に(2/2)
68. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. We're Hiring! CTO Tori Kaminashi, Inc.
69. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Thank you! © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 鈴木 健太郎 @szk3