Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Dr. WarnerのKeynoteで発表された THE FRUGAL ARCHITECTから学ぶ トレードオフアーキテクチャ

Tsukasa Kawamura
March 17, 2024
7

Dr. WarnerのKeynoteで発表された THE FRUGAL ARCHITECTから学ぶ トレードオフアーキテクチャ

re:Invent2023で発表されたTHE FRUGAL ARCHITECTについて解説と考察を行っています。

Tsukasa Kawamura

March 17, 2024
Tweet

Transcript

  1. © 2023 NTT DATA Corporation © 2023 NTT DATA Corporation

    Dr. WarnerのKeynoteで発表された THE FRUGAL ARCHITECTから学ぶ トレードオフアーキテクチャ 2023年12⽉21⽇ NTTデータ 川村 吏
  2. © 2023 NTT DATA Corporation 4 ⾃⼰紹介 ・名前︓川村 吏(かわむら つかさ)

    ・所属︓株式会社NTTデータ 社会基盤ソリューション事業本部 ・業務︓ 2015年中ころ〜2019年初頭まで︓オンプレミス環境(VMware、Xen、Hyper-V等)を中⼼とした、基盤設計、構築、運⽤等 2019年初頭〜2020年10⽉︓パブリッククラウド(AWS中⼼、Azureも少し)へのリフト、シフト、新規開発における提案、基盤設計、構築 2020年11⽉〜︓NTTデータ社へ中途⼊社 公共機関向けシステムのクラウド移⾏に関するコンサル、提案、設計、構築など ・好きなAWSサービス︓ S3、CloudFront、Route53 ・趣味︓ 猫、Disney、グラス収集、紅茶、料理、etc…
  3. © 2023 NTT DATA Corporation 6 THE FRUGAL ARCHITECTとは︖ THE

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

    クラウドの進化 ハードウェアの制約が取り払われ、いつでも必要なリソースを ⼿に⼊れることができる 制約が取り払われる⼀⽅で、コストを念頭に置くことが薄れ てしまっている • コストを減らすことはサスティナブルにつながる • クラウドに移⾏するだけが最適なのではない 移⾏して、クラウドに最適化すること、コストを最適化するこ とが主体である
  5. © 2023 NTT DATA Corporation 8 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. →挑戦を伴わない成功は思い込みにつながる
  6. © 2023 NTT DATA Corporation 10 LAW1. Make Cost a

    Non-functional Requirement. コストを⾮機能要件に⼊れることとは︖ 可⽤性、拡張性、セキュリティ、保守、コンプライアンス、移⾏ など、⾮機能要件は様々もののコストは⾒落とされやすい。 設計から開発、運⽤に⾄るまで、コストを適切に意識する必 要がある。 コストへの影響を早期かつ継続的に考慮することで、機能、開 発期間などバランスの取れたシステムが設計できる。 考察 セキュリティやコンプライアンスなどコストをかけざるを得ないもの はあるが、可⽤性や拡張性などはトレードオフ可能な部分。 担当するプロジェクトにおいて、どの程度コストがかかるのか、か ける必要があるのか、かけられるのかアーキテクチャとセットで考 える必要がある。 どの部分にコストがかかるのか、それは本当に必要なものなの か、ビジネス上コストをかける必要があるのか、代替⼿段はな いのかなどを要件を決める段階で検討する必要がある。
  7. © 2023 NTT DATA Corporation 12 LAW2. Systems that Last

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

    Series of Trade-offs. アーキテクチャはトレードオフの連続であるとは︖ アーキテクチャにおいて、あらゆる要素はトレードオフが伴う。可⽤性や、パフォーマンスなどは相互に影響し合う関係性である。 技術的なニーズとビジネス上のニーズの適切なバランス、リスク許容度と予算にあったポイントを⾒つけることが重要 何に対してコストを⽀払う価値があるのかを⾒極める必要がある。 考察 可⽤性をとると、コストやパフォーマンスを犠牲にする、パフォーマンスを優先すると可⽤性、コストを犠牲にする、コストを優先すると、 パフォーマンスや可⽤性を犠牲にするなど、あらゆる項⽬はトレードオフである。システムで提供するものがどのようなビジネス上の特 性があるのかを常に考え、コンポーネントごとに⾮機能要件を検討し、何を優先し何をトレードオフするのかを考える必要がある。例 えば、システムダウンを引き起こすとビジネス上クリティカルな影響があるのであれば、複雑性やコストを犠牲にし、災対までつくりこむ、 ビジネス上数分間ダウンしても特に売上に影響が出ないのであれば、可⽤性やパフォーマンスを多少落としコストを優先するなどの 選択ができる。この選択ができるようにするには、機能ごとに分割したアーキテクチャをとっておき、選択、調整、変更が可能なアーキ テクチャとする必要がある。
  9. © 2023 NTT DATA Corporation 16 LAW4: Unobserved Systems Lead

    to Unknown Costs. 観測と測定ができないシステムは未知のコストを⽣み出すとは︖ システム上監視や測定を実施してない場合、実際に何にコストがかけられているのかが把握できない。 コストに関する指標をエンジニアとビジネス上の決定を下す⼈に⾒えるようにする必要がある。 考察 我々⾃⾝コストが⾒えていないと無駄に使ってしまう傾向がある。たとえば、家計でも同じで、電気代、⾷費はどのくらいかけている のか、把握するだけで⾃⾝の⾏動が変わる。売上とコストを適切にモニタリングすることで、機能の改善や廃⽌を含めた適切な判 断ができる。 システム全体のコストも重要だが、機能単位で効果的な使い⽅ができているのか、ビジネス上の判断を⾏うために、指標を定義し、 コスト、リクエスト数などの収集と確認をすべき。
  10. © 2023 NTT DATA Corporation 18 LAW5. Cost Aware Architectures

    Implement Cost Controls. コストを意識したアーキテクチャはコスト管理を実現するとは︖ コストを意識したアーキテクチャをとると、モニタリングに応じた調整や改善が常に可能な状態となるため、⾃然とコスト管理ができる ようになる。これを実現するためには、コンポーネントを分解し階層化、層ごとにコストと⾮機能要件を検討し、トレードオフができる ようになる。 考察 コンポーネントごとに、ビジネス上の特性を理解し、要件とコストのトレードオフを図ることが⼤切である。本質は、そのコンポーネント に対してビジネス上の判断が下った際に、調整が容易にできること、それができるアーキテクチャ、モニタリングをしておくことが⼤切で ある。
  11. © 2023 NTT DATA Corporation 20 LAW6. Cost Optimization is

    Incremental. コストの最適化は段階的に⾏うとは︖ コストの最適化は、継続的に⾏う必要がある。導⼊後もシステム全体を再検討し、段階的な最適化が必要である。 考察 システムは設計開発が主体ではない、運⽤が始まってからが本番である。そのため、運⽤が始まってからでも、継続 的にシステムを分析モニタリングし、コストの削減箇所を常に探る。そのためには、継続的なモニタリングと改善をサイ クルに⼊れる必要がある。
  12. © 2023 NTT DATA Corporation 22 LAW7. Unchallenged Success Leads

    to Assumptions. 挑戦を伴わない成功は思い込みにつながるとは︖ ⼤きな失敗などを伴わずに収めた成功は、成功例として過信してしまう傾向がある。 過去にこの⽅法で成功した、やったことがあるだけでは、最適とは限らない。 考察 我々が陥りやすい罠。常に最良の選択がなにか、費⽤対効果、効率などさまざまな新しい選択肢を模索する必要がある。開発 ⼿法、開発⾔語、アーキテクチャ等々常に我々は最新の情報を把握し、最適なものを提供する必要がある。 また、運⽤を意識する必要がある。コストの殆どが運⽤のコストであるため、開発時のコストはもちろん意識する必要があるが、運 ⽤時のコストを常に念頭に⼊れるべし。 Most Dangerous Phrase “We’ve always done it this way.”
  13. © 2023 NTT DATA Corporation 24 まとめ トレードオフなアーキテクチャを構築する 1. コストを下げる努⼒をし続けること

    2. お客様のビジネス特性を理解すること 3. ビジネスにおける売上と、システム上のメトリクス、コストを常に関連付けてモニタリングすること 4. お客様のビジネス特性に合わせて、トレードオフな⾮機能要件を構成すること 5. 進化可能なアーキテクチャをとること 6. モニタリングしたデータに基づき、ビジネス上の判断を⾏い、その判断を容易にシステムに反映できるようにすること 7. これまでの経験や常識を疑うこと
  14. © 2023 NTT DATA Corporation 25 最後に ワーナーは、すべてのエンジニアはAWSのサービスを購⼊する決定を下しているという意識をする必要があると述べていました。 システムを構成する技術要素やパラメータは、そのシステムによる問題解決やお客様への価値提供につながるべきです。 AWSは、様々なサービスや、サービスにおけるトレードオフな選択を⽤意しています。(例︓様々な開発⾔語、コンテナワークロー

    ド、可⽤性や性能に関するオプション などなど)我々は、お客様が実現したいことを叶えるために、適切にサービスを構成し、ト レードオフをしながら構成要素を決定していく必要があります。我々がコストにかかる決定の⼀貫を担っていること、そしてそのコスト については必ずビジネスの要素とシステム上のメトリクスをモニタリングし、改善し続けること、そのためには進化可能なアーキテクチャ を取る必要があるのです。これを常に意識してお客様のビジネスに貢献できるような、開発者となっていこうと思います。
  15. © 2023 NTT DATA Corporation 26 References • AWS re:Invent

    2023 - Keynote with Dr. Werner Vogels https://youtu.be/UTRBVPvzt9w?si=pJeThqqCqLXuPpdg • THE FRUGAL ARCHITECT https://thefrugalarchitect.com/