技術的負債になりかけていた機能をリアーキテクティングしたらめちゃくちゃ改善した話 / 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

View Slide

技術的負債になりかけていた機能を
リアーキテクティングしたら
めちゃくちゃ改善した話
鈴木健太郎 (@szk3)
C - 3
ソフトウェアエンジニア
株式会社カミナシ

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

旧アーキテクチャと、抱えていた課題

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

バッチ処理は1プロセスで動くため、プロセスごとエラーになると
全ての変換処理に対して、リカバリ処理を行う必要があった
3. バッチ処理が失敗するとスクラムに影響が大きい(1/2)
goroutine (1..n)
job
job
job
job
xlsx
Wait
Wait
container
Timeout at AWS CodeBuild
Recovery targets
process kill

View Slide

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

View Slide

旧システムアーキテクチャ課題 (再掲)

View Slide

新アーキテクチャと、解決できた課題

View Slide

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

View Slide

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

View Slide

新システムアーキテクチャ
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
Service (Amazon ECS)
Container
AWS Fargate
Service (Amazon ECS)
Job Scheduling
5
6
Find export data
Create xlsx file
Amazon Aurora

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

責務の分割
AWS Cloud
xlsx
Triger
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

View Slide

非同期処理とスケールアウトの実現
AWS Cloud
xlsx
Triger
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

View Slide

影響範囲の限定化
AWS Cloud
xlsx
Triger
Job Submit
1
2
3 4
AWS Batch
AWS Fargate
Container
AWS Fargate
Job Scheduling
5 Find export data
影響範囲の限定化
Amazon Aurora

View Slide

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

View Slide

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

View Slide

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

View Slide

AWS Batch と AWS Fargate でリアーキテクティングした結果
▶ スケールアウトできる仕組みの実現
新システムアーキテクチャまとめ(1/3)

View Slide

▶ AWSリソースの利用コストを約90%程度削減
(※ ほぼAWS CodeBuild のコストだった)

View Slide

▶ 監視の仕組みを追加
▶ リトライ処理の効率化

View Slide

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

View Slide

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

View Slide

安全に段階的ロールアウトを実現する

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

AWS AppConfig の知見共有

View Slide

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

View Slide

Terraform で差分が出続ける
• aws_appconfig_hosted_configuration_version の
content の `_updatedAt` が apply の度に変わる
▶ content を ignore changes することで回避

View Slide

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

View Slide

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

View Slide

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

View Slide

まとめ

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

We're Hiring!
CTO Tori
Kaminashi, Inc.

View Slide

Thank you!
鈴木健太郎
@szk3

View Slide

技術的負債になりかけていた機能をリアーキテクティングしたらめちゃくちゃ改善した話 / 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

kaminashi, Inc.

More Decks by kaminashi, Inc.

Other Decks in Technology

Featured

Transcript