© 2023 NTT DATA Corporation © 2023 NTT DATA Corporation THE FRUGAL ARCHITECTから読み解く観測と可視化 2023年1月19日 NTTデータ 川村 吏

© 2023 NTT DATA Corporation 2 本日お話すること 3日目のKeynoteでAmazon.comのCTO Dr.Warner Vogelsが発表したTHE FRUGAL ARCHITECTで触れられていた観測と可視化について掘り 下げて語ります。

© 2023 NTT DATA Corporation 3 自己紹介 ・名前：川村 吏（かわむら つかさ） ・所属：株式会社NTTデータ 社会基盤ソリューション事業本部 ・業務： 2015年中ころ～2019年初頭まで：オンプレミス環境(VMware、Xen、Hyper-V等)を中心とした、基盤設計、構築、運用等 2019年初頭～2020年10月：パブリッククラウド(AWS中心、Azureも少し)へのリフト、シフト、新規開発における提案、基盤設計、構築 2020年11月～：NTTデータ社へ中途入社 公共機関向けシステムのクラウド移行に関するコンサル、提案、設計、構築など ・好きなAWSサービス： S3、CloudFront、Route53 ・趣味： 猫、Disney、グラス収集、紅茶、料理、etc…

© 2023 NTT DATA Corporation 4 THE FRUGAL ARCHITECT THE FRUGAL ARCHITECT=倹約的なアーキテクト コストを意識した持続可能なモダンアーキテクチャを構成するための法則

© 2023 NTT DATA Corporation 5 THE FRUGAL ARCHITECTが生まれた背景 • クラウドの進化 ハードウェアの制約が取り払われ、いつでも必要なリソースを 手に入れることができる 制約が取り払われる一方で、コストを念頭に置くことが薄れ てしまっている • コストを減らすことはサスティナブルにつながる • クラウドに移行するだけが最適なのではない 移行して、クラウドに最適化すること、コストを最適化するこ とが主体である

© 2023 NTT DATA Corporation 6 7つの法則 LAW 1. Make Cost a Non-functional Requirement. →コストを非機能要件に取り込むこと LAW 2. Systems that Last Align Cost to Business. →コストをビジネスにあわせて調整可能にすること LAW 3. Architecting is a Series of Trade-offs. →アーキテクチャはトレードオフの連続であること LAW 4. Unobserved Systems Lead to Unknown Costs. →観測と測定ができないシステムは未知のコストを生み出す LAW 5. Cost Aware Architectures Implement Cost Controls. →コストを意識したアーキテクチャはコスト管理を実現する LAW 6. Cost Optimization is Incremental. →コスト最適化は段階的に行う LAW 7. Unchallenged Success Leads to Assumptions. →挑戦を伴わない成功は思い込みにつながる

© 2023 NTT DATA Corporation 7 観測と測定の重要性 Dr.Warnerが発表したTHE FRUGAL ARCHITECTでも触れられている通り、観測と測定は、ビジネス上の決定、コストの改 善、ユーザ体験の向上に大いに役立つ LAW4: Unobserved Systems Lead to Unknown Costs. 観測と測定ができないシステムは未知のコストを生み出すとは？ システム上監視や測定を実施してない場合、実際に何にコストがかけられているのかが把握できない。 コストに関する指標をエンジニアとビジネス上の決定を下す人に見えるようにする必要がある。 我々自身コストが見えていないと無駄に使ってしまう傾向がある。たとえば、家計でも同じで、電気代、食費はどのくらいかけている のか、把握するだけで自身の行動が変わる。売上とコストを適切にモニタリングすることで、機能の改善や廃止を含めた適切な判 断ができる。 システム全体のコストも重要だが、機能単位で効果的な使い方ができているのか、ビジネス上の判断を行うために、指標を定義し、 コスト、リクエスト数などの収集と確認をすべき。

© 2023 NTT DATA Corporation 8 LAW2. Systems that Last Align Cost to Business. コストをビジネスにあわせて調整可能にすることとは？ ビジネス上の利益に沿ってコストが増減できるアーキテクチャと すること。 例えば、Eコマースのビジネスを展開しているシステムにおいて、 注文数が増えることにより、インフラコスト、運用コストが増える ようなアーキテクチャになっていれば問題ない。これは、注文数 が増えることによって、コストが増加するが、売上も同時に上が るため。 考察 従量課金というクラウドのメリットを最大限活かしているか、更 にそれがビジネスの増減に自動でスケールする構成となっている かという点がポイントとなる。また、ビジネス上の決定と技術的 な調整が常にできる状態でなければならない。 これを実現するためには、進化可能なアーキテクチャを取ること が要求される。技術的な制約がビジネスの発展を邪魔する （技術的負債） 事はできる限り避ける必要がある。これが、モダンアーキテクチャ を構成すべき理由の一つだと思う。

© 2023 NTT DATA Corporation 9 関連するアップデート • AWS Management Console myApplications リソースに対してTagを付与することで、該当のTagが付与されたリソースのコストを マネジメントコンソール上のWidgetに表示するサービス • Amazon CloudWatch Application Signals（Preview） アプリケーションの健全性を監視し、ビジネス目標に対して長期的なアプリケーションのパフォーマンスを追跡できるサービス SLOに対して、通信量、可用性、遅延、障害、エラーなどの主要なメトリクスを紐づけ、パフォーマンスが目標を達成しているか を可視化する

© 2023 NTT DATA Corporation 10 観測と測定 ビジネスに影響のある箇所の特定と監視・測定をしてますか？ 業務やインフラ双方のサービス改善につながる監視が必要 →指標が必要

© 2023 NTT DATA Corporation 11 指標の例：SLA、SLO、SLI • SLA (Service Level Agreement) ユーザがサービスを利用する際に期待するサービスレベルの規定、契約 サービスプロバイダーとユーザーの間で締結されるもの 例：EC2のSLA 99.5% • SLO (Service Level Objective) サービスの信頼性の目標値、SLIに対して期間と目標値をつけたもの 例：１ヶ月の間で99.9％リクエストが正常に完了すること、100ms以内にリクエストが完了する割合が１ヶ月で99%など • SLI (Service Level Indicator) システムの可用性に関するユーザー体験を対象とした定量的な測定値 例：レイテンシ、レスポンスの正常割合など

© 2023 NTT DATA Corporation 12 我々（アーキテクト）に何が求められているか お客様のビジネスに対して、パフォーマンス（信頼性、性能など）と コストのバランスを考えたアーキテクチャを作る。 計測と可視化により、改善を続ける。 改善可能なアーキテクチャをとる。 • お客様のビジネス状況を正しく理解し、求められている要件が適切かどうか判断する • 指標を定義する お客様のビジネス状況から、どの程度のレスポンスが必要か、可用性が必要かなどを具体的な指標として定義する • 定義した指標を観測、可視化する • ビジネス上の数値と、観測した数値をもとにアーキテクチャの改善を繰り返す、必要に応じてSLI、SLO等の指標を見直す

© 2023 NTT DATA Corporation 13 気になるコスト関連のアップデート • AWS Cost Optimization Hub コスト最適化ハブは新しい AWS Billing and Cost Management 機能であり、EC2 インスタンスの適正サイズ化の推奨事 項、リザーブドインスタンスの推奨など、15 種類以上の AWS コスト最適化の推奨事項を、AWS アカウントと AWS リージョン全 体にわたって、1 つのダッシュボードで簡単に特定、フィルタリング、集約できる。組織単位で有効化可能。ComputeOptimizer と連携しているため、コスト管理画面で、コスト改善につながる提案とコストを比較して確認できる嬉しい機能。

© 2023 NTT DATA Corporation 14 まとめ お客様のビジネスを、パフォーマンス、コストのバランスを取りながら提供することは想像以上に難しいものです。 事前に定義しても、お客様のビジネス状況は常に変化していきます。 我々は変化するビジネス状況、システムの状況を観測、可視化し、常に改善していくこと、改善可能なアーキテクチャをとることが 求められていると感じました。 Dr.Warnerが語っていた危険なワード「“We’ve always done it this way.”」を意識して、過去の成功体験にとらわれすぎず、観測 した数値に基づいて判断を行っていきたいものです。

© 2023 NTT DATA Corporation 15 References • AWS re:Invent 2023 - Keynote with Dr. Werner Vogels https://youtu.be/UTRBVPvzt9w?si=pJeThqqCqLXuPpdg • THE FRUGAL ARCHITECT https://thefrugalarchitect.com/ • SLO、SLI、SLAとは何か? https://newrelic.com/jp/blog/best-practices/what-are-slos-slis-slas • メルペイにおけるSLOの活用事例 – 信頼性を定義しよう https://engineering.mercari.com/blog/entry/20210928-mtf2021-day4-3/ • どのようにSREを導入すればいいのか～SLI、SLO、SLA設定例 https://ggtop.jp/category-sre-blog-part3/

Thank you!