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

© 2023, Amazon Web Services, Inc. or its affiliates. All
rights reserved. J U N E 2 2 , 2 0 2 3

rights reserved. 鈴木健太郎 / Kentaro SUZUKI @szk3 株式会社カミナシエンジニアリング本部 Harami Enginieering 第２ユニットソフトウェアエンジニア自己紹介

rights reserved. 想定受講者 • バッチ処理のリプレイスや改善を検討しているアーキテクト、ソフトウェアエンジニアゴール • 紹介事例を通じて、設計の選択肢が広がること本セッションは

rights reserved. • AWS CodeBuild • AWS Batch • AWS Fargate • AWS AppConfig 登場する主なAWSのソリューション／サービス

rights reserved. 話すこと • 技術的負債になりかけていた機能のリアーキテクティング事例紹介 • AWS Batch を使ったリアーキテクティング • AWS AppConfig を使った段階的ロールアウト話さないこと • 各AWSのソリューション／サービスの具体的な説明や詳細な使い方話すこと、話さないこと

rights reserved. • 旧アーキテクチャと、抱えていた課題 • 新アーキテクチャと、解決できた課題 • 安全な段階的ロールアウトを実現する • AWS AppConfig の知見共有 • まとめアジェンダ

rights reserved. お客様は業務上発生する紙への記録（点検, 食品衛生管理など）を、タブレットやスマートフォンで入力することができます（ ※これらは、カミナシが提供する機能のひとつです）前提カミナシの提供するサービス

rights reserved. Excel変換 • カミナシに保存された帳票記録をExcel形式に変換して出力する機能 • 定期的に繰り返されるバッチ処理による変換出力リアーキテクティングの対象となった機能帳票記録DB xlsx

rights reserved. 利用状況の変化 • 設計当初と課題になりつつあった時期を比較すると、記録された帳票の数は約4倍ほどに増加していた • 利用者の増加とともに、設計当初のシステムアーキテクチャが技術的負債となっていたリアーキテクティングの背景

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

rights reserved. １．バッチ処理のスループットを上げにくい２．AWSリソースの利用コストが無駄にかかる３．バッチ処理が失敗するとスクラムに影響が大きい旧システムアーキテクチャ課題

rights reserved. バッチ処理の完了時間や処理量が見積もりにくい • 1回のバッチで処理するデータ量は利用状況により変動する • 特定のタイミング(月末/月初など)で処理時間が長くなる 1. バッチ処理のスループットを上げにくい(1/3)

rights reserved. バッチ処理の実行環境である AWS CodeBuild がタイムアウトするという問題が発生 • AWS CodeBuild のタイムアウトを段階的に伸ばす暫定対応を実施 1時間 → 3時間 → 8時間（※AWS CodeBuild の仕様上の上限値） 1. バッチ処理のスループットを上げにくい(2/3)

rights reserved. また、タイムアウトを上限まで伸ばしたタイミングで、 AWS CodeBuild の割当リソース設定も限界までスケールアップ • 本対応の目的は、”少ない工数”で障害になりにくい状態を作ること • バッチ処理に長い時間がかかる事実は変わらない • この時点で、スケールアップの余地はなくなった • バッチ処理の改修や、インフラのスケールアウトなしにスループットを上げにくい状態になっていた 1. バッチ処理のスループットを上げにくい(3/3)

rights reserved. 予測が難しい負荷を考慮し、上限までスケールアップした結果 • AWS CodeBuild の利用コストは約4倍になった ※ ほとんどのバッチ処理で、これほどのリソースは不要 2. AWSリソースの利用コストが無駄にかかる

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

rights reserved. 3. バッチ処理が失敗するとスクラムに影響が大きい(2/2) リカバリ担当者による手動オペレーションが必要 • 当時のシステムはクラウド側でリトライすることを前提としたコードやシステムアーキテクチャになっていなかった・エンジニアが、ローカル環境でソースコードを書き換えて、ハイコンテキストなリカバリ処理を実行・経験豊富なエンジニア1-2人で1営業日程度の時間を要した

rights reserved. １．バッチ処理のスループットを上げにくい２．AWSリソースの利用コストが無駄にかかる３．バッチ処理が失敗するとスクラムに影響が大きい旧システムアーキテクチャ課題 (再掲)

rights reserved. Design Doc を記述し、関係者の認識をあわせる • これまでの対応状況と現状の整理 • リアーキテクティングのアウトカムの定義 • 課題を解決するためのアーキテクチャ設計案リアーキテクティングの事前準備

rights reserved. リアーキテクティングの結果、どんな状態になりたいのかを言語化 • 変換処理が集中する月初の目標処理時間を1時間以内に • 2-3 年後を想定した変換処理量を問題なく処理できるリアーキテクティングのアウトカムを定める

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

rights reserved. AWS Batch を中心に再構築し、スケーラビリティを確保 • アプリケーションを責務で分離 • リカバリ処理の効率化 • AWS Batch と AWS Fargate で全体的なコストの最適化新システムアーキテクチャのポイント

rights reserved. AWS CodeBuild のコンピュートリソース上で実行していたコンテナを AWS Batch on AWS Fargate で実行するように再構築非同期処理にAWS Batchを採用、変換処理のスケールアウトを実現 AWS Batch を中心に再構築 AWS CodeBuild AWS Fargate AWS Batch Docker Container before after

rights reserved. バッチ処理をスケールアウトさせることができ、運用負荷が低い • スケーラブルなキューイング機能 • コスト最適化されたスケーリング性能 • AWS Batch 自体の利用は無料 (※ ジョブを実行するコンピュートリソースなどは有料です） • リトライの容易さ AWS Batch を選んだ理由

rights reserved. • 1つの変換処理で最大20分程度かかるケースを観測していた為、 AWS Lambda は最大実行時間の制限により選択肢から除外（ ※現時点での最大実行時間は15min ） AWS Fargate を選んだ理由

rights reserved. AWS Batch への Job Submit の部分は、AWS Lambda を用いる設計も検討したが、現状のメンバーで運用していくことを見据えながら、変えすぎない部分について議論し、チームで合意した優先させたこと • 既存の技術スタックに合わせる • 既存のデプロイフローの流れに寄り添う AWS Fargate 以外の設計案

rights reserved. アプリケーションを "変換処理のEnqueue" と "変換処理" に分割 • 変換処理を非同期的に処理し、スケールアウトできるようにする • 変換処理を独立して処理し、失敗時の影響範囲を限定的にするアプリケーションの分割

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

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

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

rights reserved. リカバリ手法を再設計し、AWS Batch で再試行を自動化 • AWS Batch で 3回まで再試行を実施 • 再試行で失敗であれば、ジョブをクローンしリトライするリカバリの効率化 https://docs.aws.amazon.com/ja_jp/batch/latest/userguide/job_retries.html

rights reserved. 利用するリソース利用料の最適化 • AWS CodeBuild の利用コストを約90%程度削減コストの最適化

rights reserved. 通知の導入 • AWS Chatbot を使ったSlackへの連携処理失敗時の検知の仕組み ※画像は一部マスクしています

rights reserved. AWS Batch と AWS Fargate でリアーキテクティングした結果１．バッチ処理のスループットを上げにくい ▶ スケールアウトできる仕組みの実現新システムアーキテクチャまとめ(1/3)

rights reserved. AWS Batch と AWS Fargate でリアーキテクティングした結果２．AWSリソースの利用コストが無駄にかかる ▶ AWSリソースの利用コストを約90%程度削減 (※ ほぼAWS CodeBuild のコストだった) 新システムアーキテクチャまとめ(2/3)

rights reserved. AWS Batch と AWS Fargate でリアーキテクティングした結果３．バッチ処理が失敗するとスクラムに影響が大きい ▶ 監視の仕組みを追加 ▶ リトライ処理の効率化新システムアーキテクチャまとめ(3/3)

rights reserved. 変換処理が集中する月初の目標処理時間を1時間以内に ▶ 先月比較で2時間7分(127分) → 29分＝処理時間は約1/4 に (※ 移行時の数値 ) 2-3 年後を想定した変換処理量を問題なく処理できる ▶ 今のスループットから、十分に処理できると判断アウトカムの達成度

rights reserved. 実装しなかったこと • 変換処理失敗時のチケット管理システムへの連携 • 処理の重み付けのような、既存にはない機能やらなかったこと

rights reserved. 新旧システムを併用しながら、機能フラグ(Feature Flags)を用いて段階的なロールアウトを実施した • おそよ1ヶ月程度の併用期間 • カスタマーサポート(CS)チームがサポートしやすい移行計画安全に段階的ロールアウトを実現する

rights reserved. 本番ワークロードにおいて新システムがもたらす不確実性を排除する • ロールバックのしやすさを重視 • リリースとカットオーバーを分離し、ビッグバンリリースを避ける • 想定されるリスクの段階的検証機能フラグを用いる背景

rights reserved. • 環境変数 • コンテナに反映するのに Amazon ECS タスク定義の修正が必要 • AWS Systems Manager Parameter Store • 必要最低限で良い (設計当初の第一候補) 機能フラグの実装案(1/3)

rights reserved. • Amazon DynamoDB テーブル • データ構造を柔軟に管理できるがゆえに、迷いを生む可能性 • Amazon CloudWatch Evidently • Validation name が大量になるようなケースへの適用は難しい (※ 設計当時の考慮から漏れてたので、後から考えた結果このように判断) 機能フラグの実装案(2/3)

rights reserved. • AWS AppConfig 機能フラグ • 段階的ロールアウトの移行粒度を表現しやすかった • とはいえ、AWS Systems Manager Parameter Store でも実装は可能機能フラグの実装案(3/3)

rights reserved. 機能フラグのマネージドサービスとして、知見を貯めたかった • ソースコードのデプロイが不要 • フラグの制約やバリデーターなどのガードレール (※) • CloudWatch アラームをトリガーにフラグの自動ロールバック (※) (※ これらは選んだ理由としてはあげていますが、今回のタイミングでは使えておりません) AWS AppConfig を選んだ理由

rights reserved. • 仮に何かしらのトラブルが発生した際に、カスタマーサポート／サービスチームと連携し、迅速に対応したかった • ロールアウトの粒度は、帳票記録の利用頻度や想定される出力処理の量などを可能な限り調査し、お客様を5つのグループに分類して、グループ単位でロールアウトしていった段階的ロールアウトの計画利用頻度が低い利用頻度が高い Group 5 Group 4 Group 3 Group 2 Group 1

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

rights reserved. 新旧環境の併用における、Amazon Aurora への負荷のリスク • 旧システムと新システムは排他制御で、処理の総和は変化しない • 新システムはスケールアウトするので、瞬間的に負荷が高くなるリスクが想定されていた想定されるリスクの段階的検証 AWS Cloud Container Previous system Current system AWS Fargate Amazon Aurora

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

rights reserved. 無事に全ての移行が完了 • 特に大きなトラブルなし • 段階的ロールアウト中に、失敗時のRunbookが有効性を確認 • AppConfig 関連のリソースやソースコードは削除 • 旧システムも経過観察後にシャットダウン安全に段階的ロールアウトを実現する - まとめ

rights reserved. Terraform 経由で想定したリソースが作成できなかった • 当時の AWS Provider が古く、機能フラグではなく自由フォーマットのリソースとして作成されてしまった ▶ AWS Provider の verupで解決 (v3.57.0 -> v4.46.0) AWS AppConfig 関連のトラブル(1/3)

rights reserved. Terraform で差分が出続ける • aws_appconfig_hosted_configuration_version の content の `_updatedAt` が apply の度に変わる ▶ content を ignore changes することで回避 AWS AppConfig 関連のトラブル(2/3)

rights reserved. 本番環境の AWS AppConfig リソースが作られる前に、旧システムの改修コードがデプロイされてしまった • 前述のトラブルを解消するために開発環境で検証が継続中だった • IaCのデプロイフローとアプリケーションのデプロイフローが別 ▶ 関係各位を巻き込み、リカバリ対応を行った AWS AppConfig 関連のトラブル(3/3)

rights reserved. 最新の設定をもってくる GetLatestConfiguration API は有料です • バッチ処理のくらいの起動頻度であれば許容できるコストも、大量のトラフィックを受けるWebサイトなどでリクエスト単位でコールすると、コストが想定以上になる可能性があります AWS AppConfig GetLatestConfiguration API https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_appconfigdata_GetLatestConfiguration.html

rights reserved. AWS AppConfig のサイドカーコンテナが公開されている • 内部的に設定をキャッシュしてくれてローカルのHTTPリクエストを通じて機能フラグを取得してくれて、実装もシンプルになる AWS AppConfig のサイドカーコンテナ https://gallery.ecr.aws/aws-appconfig/aws-appconfig-agent

rights reserved. AWS Batch と AWS Fargate でシステムアーキテクチャを刷新し、 AWS AppConfig を使って段階的なロールアウトを実現バッチ処理のリアーキテクティング AWS AppConfig AWS Batch AWS Fargate

rights reserved. スケールアウトの上限をコントロール ▶ AWS Batch のコンピューティングリソースで試算可能非同期処理により、スループットの向上 ▶ 繁忙時間帯の処理時間は4分の1以下コントロールしやすいスケールアウト

rights reserved. 変換処理の信頼性を向上 ▶ アプリの責務を分割し、エラー時の影響範囲を限定的にハイコンテキストで時間がかかるリトライ作業からの脱却 ▶ AWS Batch の Job を再実行するだけにリカバリ負荷の低減

rights reserved. AWS CodeBuild から AWS Batch へシフト ▶ AWS CodeBuild リソース利用量を約90%削減 ▶ AWS Batch 自体の利用は無料 AWSサービス／リソースの利用コストを最適化

rights reserved. AWS AppConfig の機能フラグ (Feature Flags) を用いて、本番ワークロードへの段階的ロールアウトを実現 ▶ 影響範囲を最小化 ▶ ロールバックしやすい状態の構築機能フラグを用いた段階的ロールアウト

rights reserved. アーキテクチャやコンテキストが完全に同じものは存在しない。だからこそ、最適なアーキテクチャを検討しつづける必要がある。故に当時の設計を安易に否定せず、受け入れてちょっとだけ改善し今のメンバーで一緒に前に進んでいくことが大切。最後に(1/2)

rights reserved. ベストプラクティスが正解である保証はどこにもありません。選んだアーキテクチャを正解にしていくという姿勢が大事。（最大限考慮してやってダメなら、またやり直せばいい）最後に(2/2)

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

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

More Decks by kaminashi, Inc.

Other Decks in Technology

Featured

Transcript