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