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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© 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…

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

© 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. →挑戦を伴わない成功は思い込みにつながる

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 2023 NTT DATA Corporation 24 まとめトレードオフなアーキテクチャを構築する 1. コストを下げる努⼒をし続けること 2. お客様のビジネス特性を理解すること 3. ビジネスにおける売上と、システム上のメトリクス、コストを常に関連付けてモニタリングすること 4. お客様のビジネス特性に合わせて、トレードオフな⾮機能要件を構成すること 5. 進化可能なアーキテクチャをとること 6. モニタリングしたデータに基づき、ビジネス上の判断を⾏い、その判断を容易にシステムに反映できるようにすること 7. これまでの経験や常識を疑うこと

Slide 25

Slide 25 text

© 2023 NTT DATA Corporation 25 最後にワーナーは、すべてのエンジニアはAWSのサービスを購⼊する決定を下しているという意識をする必要があると述べていました。システムを構成する技術要素やパラメータは、そのシステムによる問題解決やお客様への価値提供につながるべきです。 AWSは、様々なサービスや、サービスにおけるトレードオフな選択を⽤意しています。（例︓様々な開発⾔語、コンテナワークロード、可⽤性や性能に関するオプションなどなど）我々は、お客様が実現したいことを叶えるために、適切にサービスを構成し、トレードオフをしながら構成要素を決定していく必要があります。我々がコストにかかる決定の⼀貫を担っていること、そしてそのコストについては必ずビジネスの要素とシステム上のメトリクスをモニタリングし、改善し続けること、そのためには進化可能なアーキテクチャを取る必要があるのです。これを常に意識してお客様のビジネスに貢献できるような、開発者となっていこうと思います。