231209 Shinshin TechLive 登壇資料
712 Views
December 12, 23
スライド概要
関連スライド
各ページのテキスト
資格9冠ビジネス職 Notion Ambassador 帰国⼦⼥からみたre:Invent 11th of Dec 2023, at Fusic TechLive Vol.17 1
⾃⼰紹介 Role at Fusic Skill Shinshin a.k.a., ・むろいくん ・シンくん ・Shaigne (English Name) § § 事業推進部⾨チームAWS所属 AWSセールス、コンサルタント、ソリューションアーキ テクト、チーム海外、英語の⼈、ガヤガヤ § AWS § § 英語（学⽣時代イギリス） Notion Ambassador § § Github︓Shinshin1313 X（旧Twitter）︓@shin13fs6x SNS 2
たくさんおもいで 3
たくさんおもいで 4
たくさんおもいで 5
たくさんおもいで 6
たくさんおもいで 7
たくさんおもいで 8
たくさんおもいで 9
たくさんおもいで 10
たくさんおもいで 11
喋る内容、結構悩んだ 海外Techな話いいなー 量⼦コンピューターいいなー Amazon Qでもありだなー 12
悩んだ結果 まようなー、まようなー 13
Warner VogelsのKeynoteがいいvibesだった なんかちょっと哲学チック 私、⼤学で哲学を専攻 古代ギリシャ哲学から現代の倫理哲学までざっくりやったYO︕ 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 14
Warner VogelsのKeynoteがいいvibesだった なんかちょっと哲学チック 私、⼤学で哲学を専攻 ! ! ! … い な か し る や 古代ギリシャ哲学から現代の倫理哲学までざっくりやったYO︕ 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 15
Warner Veglsʼ Keynoteより︕ The Frugal Architectを振り返る︕︕︕ 11th of Dec 2023, at Fusic TechLive Vol.17 16
Who is Warner Vogels? ワーナー・ハンズ・ピーター・ヴォゲルス （Werner Hans Peter Vogels、1958年10 ⽉3⽇ - ）はAmazon.comの最⾼技術責任者 兼副社⻑であり、社内での技術⾰新の推進を 担当している。 2008年にヴォゲルスがアマゾンのクラウド コンピューティング事業に進出したAmazon Web Services (AWS)の影にいる設計者の⼀ ⼈だということが明らかになった。 その年の間に、ヴォゲルスは切れ⽬なくクラ ウドコンピューティングとAWSとそれらの 業界へのメリットを売り込み続けた。 引⽤: Wikipedia 17
The Frugal Architect Points!!! q コストを念頭に置いたArchitecting（設計）思想 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 18
The Frugal Architect Points!!! q コストを念頭に置いたArchitecting（設計）思想 q Cost-Awareな設計は現代における失われた美学 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 19
The Frugal Architectの誕⽣の背景 オンプレ時代 - クラウド到来 必要なサーバー・ディスクスペック ネットワーク機器 サーバールーム設置・レンタル代⾦ 光熱費・保守⼈員費⽤ を、向こう数年のスケールを予測して設計 クラウド時代 - 固定費⽤がかからず - APIリクエストベースでのその都度課⾦ - 柔軟に課⾦ペースを調整できる とりあえず動かしみて、課⾦を計れるよう になった 20
The Frugal Architect Points!!! q コストを念頭に置いたArchitecting（設計）思想 q Cost-Awareな設計は現代における失われた美学 q Design, Measure, Optimizeの3チャプターで、クラウド時代において重要な7 つの法則を実体験・事例・ユーモアを交えながら解説 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 21
7つの法則 Design 1. コストを⾮機能要件の1つとして考えよ 2. ビジネスに即した設計をすべし 3. 設計は常にトレードオフだ Measure 4. 監視されていないシステムは未知のコストを⽣む 5. コストを意識したアーキテクチャーはコスト管理を実践している Optimize 6. コストの最適化は段階的である 7. 異論のない成功は過信のキッカケ 22
7つの法則 Design 1. コストを⾮機能要件の1つとして考えよ 2. ビジネスに即した設計をすべし 3. 設計は常にトレードオフだ Measure 4. 監視されていないシステムは未知のコストを⽣む 5. コストを意識したアーキテクチャーはコスト管理を実践している Optimize 6. コストの最適化は段階的である 7. 異論のない成功は過信のキッカケ 23
法則の紹介に⼊る前に︕
Cost Optimized = More Sustainable 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 25
サステナビリティ例（DynamoDBの場合） 顧客 1回だけ読む（返されるValueが最新じゃない可能性がある） AWS Cloud 1. Consistent Read Amazon DynamoDB 2. Strongly Consistent Read Virtualization（仮想化） 2回読む（より最新のValueが返される） AWS Data Centres 26
サステナビリティ例（DynamoDBの場合） 顧客 - 物理サーバーに負荷がかかりやすい（よりCPUを使う） - ⾦額がConsistent Readの倍 AWS Cloud 1. Consistent Read Amazon DynamoDB 2. Strongly Consistent Read Virtualization（仮想化） 2回読む（より最新のValueが返される） AWS Data Centres 27
サステナビリティ例（DynamoDBの場合） サステナブルじゃない…!!! 顧客 - 物理サーバーに負荷がかかりやすい（よりCPUを使う） - ⾦額がConsistent Readの倍 AWS Cloud 1. Consistent Read Amazon DynamoDB 2. Strongly Consistent Read Virtualization（仮想化） 2回読む（より最新のValueが返される） AWS Data Centres 28
Every Engineering Decision is a Sustainability Decision 顧客 More Sustainable 1回だけ読む（返されるValueが最新じゃない可能性がある） AWS Cloud 1. Consistent Read Amazon DynamoDB 2. Strongly Consistent Read Virtualization（仮想化） AWS Data Centres 29
Cost Optimized = More Sustainable 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 30
7つの法則 Design 1. コストを⾮機能要件の1つとして考えよ 2. ビジネスに即した設計をすべし 3. 設計は常にトレードオフだ Measure 4. 監視されていないシステムは未知のコストを⽣む 5. コストを意識したアーキテクチャーはコスト管理を実践している Optimize 6. コストの最適化は段階的である 7. 異論のない成功は過信のキッカケ 31
Chapter1 - Design 法則その02 Systems that Last Align Cost to Business （ビジネスに即した設計をすべし）
ビジネスの収益と、技術設計は⼀致すべき 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 33
ある通信事業者の例 GBの利⽤量で収益を上げるモデルなのに、無闇に無制限使い放題を 導⼊しちゃった場合 Capped Model（定額GB制） 利益 Unlimited（無制限使い放題） ⾚字 30GB 20GB 10GB 予期せぬ消費者⾏動の変化 34
ある通信事業者の例 GBの利⽤量で収益を上げるモデルなのに、無闇に無制限使い放題を 導⼊しちゃった場合 Capped Model（定額GB制） Unlimited（無制限使い放題） は り 売 安 の 術 技 い な さ 即 ⾚字 に ク ッ 利益 ジ ロ ジネス ︕ ビ る め 絞 を ⾸ 30GB ⾃分の 20GB 10GB 予期せぬ消費者⾏動の変化 35
AWS Lambdaも最初はそうだった（︕︖） 引⽤: https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ 36
サービスリリース当初のLambdaの例 t2インスタンス数 ≃ 顧客数 顧客 Lambda環境 Virtualization t2 t2 t2 t2 t2 t2 t2 t2 t2 t2 Hypervisor CPU 引⽤: https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ 37
サービスリリース当初のLambdaの例 t2インスタンス数 ≃ 顧客数 顧客 Lambda環境 Virtualization t2 2つ t2 t2 ! ! ! . . . が 点 題 問 の t2 t2 t2 t2 t2 t2 t2 Hypervisor CPU 引⽤: https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ 38
問題点① 顧客数のスケール 顧客 Lambda環境 Virtualization t2 t2 t2 t2 t2 t2 t2 t2 t2 t2 Hypervisor より多くの顧客をホストできるようなスケーラブルな仮想化構造で はなかった CPU 引⽤: https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ 39
問題点② t2インスタンスの低CPU利⽤率 § Lambda Functionsを実⾏するために、専⽤のEC2環境を顧客 ごとに払出し § t2インスタンス1台は、Lambda Functionsを動かすのに余分 すぎるスペック § AWS側の仮想化層・物理層におけるサーバーCPUの Underutilization（低利⽤）が発⽣ → リソースの無駄 t2 【課題】 より多くの顧客にCPU活⽤効率よくLambda環境を提供する必要があった 引⽤: https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ 40
細分化することにより、各VM環境の利⽤効率UP より多くの顧客にLambda環境の提供を可能に︕ 顧客 Lambda環境 Firecracker Virtualization t2 t2 t2 t2 t2 t2 t2 t2 t2 t2 Hypervisor CPU 引⽤: https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ 41
ビジネスロジックをFollowするアーキテクチャーへ進化させた 当初のLambda 現代のLambda Firecracker導⼊ - t2インスタンス数単位でしかLambda環境を作れなかった （=顧客のスケールに対応が難しかった） - 各インスタンスのCPU使⽤率が安定しなかった （=効率的なリソース利⽤と、ビジネス収益化ができなかった） - MicroVMsの導⼊により各ホスト環境の効率化に成功 - More Lambda Functions, More Customersを実現 - 効率的なリソース利⽤により、ビジネス収益を実現 42
Chapter1 - Design 法則その02 Systems that Last Align Cost to Business （ビジネススケールに即した設計をすべし） 【Takeaway】 Build Evolvable Architecture. ビジネスモデルに即した、進化し続ける設計を続けなさい︕
Chapter2 - Measure 法則その04 Unobserved Systems Lead to Unknown Costs （監視されていないシステムは未知のコストを⽣む）
Amsterdumでの電⼒消化事情 同じような建物でも、建物によって電⼒消化が異なる → 何故︖︖︖ 45
Amsterdumでの電⼒消化事情 地下にブレーカーがある建物 = 電⼒消化に気付きずらい More Cost More Cost More Cost 46
Amsterdumでの電⼒消化事情 地下にブレーカーがある建物 = 電⼒消化に気付きずらい More Cost More Cost ︕ る え 整 More Cost を 境 環 る き で 析 分 ・ 知 検 に 切 適 を ト コス 47
Amazon.comのCost Metrics Transitive Cost/Request （アプリ/システムレベル） Cost/Request （マイクロサービスレベル） Conversion Cost/Request （サービスレベル） 48
Amazon.comのCost Metrics Transitive Cost/Request （アプリ/システムレベル） ただ、いう っ 化 視 可 の てもここ 〜 ね よ す で て難しい Cost/Request （マイクロサービスレベル） Conversion Cost/Request （サービスレベル） 49
NEW!!! AWS Management Console myApplications 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 50
NEW!!! AWS Management Console myApplications 、 ん せ ま り ︕ お ︕ て ︕ れ ん 触 せ だ ま ま い ざ ご 訳 申し 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 51
NEW!!! AWS Management Console myApplications 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 52
NEW!!! AWS Management Console myApplications 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 53
NEW!!! AWS Management Console myApplications 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 54
NEW!!! AWS Management Console myApplications 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 55
NEW!!! AWS Management Console myApplications に便利 け 分 仕 の ス リック ト メ ・ グ ロ プリの ア 数 複 必要 の が で 化 内 効 ト 有 ン の ウ 能 - アカ rer機 o l p x E e c r u eso ます） え 使 - Tag機能、R も で 阪 京、⼤ 東 （ 始 開 ⽤ - ⼀般利 …!!! t s o C l a n o i t - No Addi 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 56
NEW!!! Amazon CloudWatch Application Signals 引⽤: https://aws.amazon.com/blogs/aws/amazon-cloudwatch-application-signals-for-automatic-instrumentation-of-your-applications-preview/ 57
NEW!!! Amazon CloudWatch Application Signals 、 ん せ ま り あ が ︕ S ん K せ E ま る 触れ 訳ござい 申し 引⽤: https://aws.amazon.com/blogs/aws/amazon-cloudwatch-application-signals-for-automatic-instrumentation-of-your-applications-preview/ 58
NEW!!! Amazon CloudWatch Application Signals ック ェ ド チ ー 性 ボ ⽤ ュ 可 APIの ダッシ 、 な t l 動 i u 変 b の e r シ P イテン レ 、 ム ー ュ リ - リクエストボ 、異変の検知など 定 依存関係の特 引⽤: https://aws.amazon.com/blogs/aws/amazon-cloudwatch-application-signals-for-automatic-instrumentation-of-your-applications-preview/ 59
NEW!!! Amazon CloudWatch Application Signals 可能 定 設 も ） s e iv t c l Obje e v e L e ic v r e S に︕） - 独⾃SLO（ 能 可 が 化 適 最 ⽤ Sの運 （チームでのEK 引⽤: https://aws.amazon.com/blogs/aws/amazon-cloudwatch-application-signals-for-automatic-instrumentation-of-your-applications-preview/ 60
NEW!!! Amazon CloudWatch Application Signals 能 可 定 設 も ） s e iv t l Objec e v e L e ic v r e S に︕ ） - 独⾃SLO（ 能 可 が 化 適 最 ⽤ Sの運 K E の で ム ー チ （ 可能 ⽤ 利 で w ie v e r P のみ ン ョ ジ ー リ 京 東 - ⽇本では 引⽤: https://aws.amazon.com/blogs/aws/amazon-cloudwatch-application-signals-for-automatic-instrumentation-of-your-applications-preview/ 61
Chapter2 - Measure 法則その04 Unobserved Systems Lead to Unknown Costs （ 監視されていないシステムは未知のコストを⽣む ） 【Takeaway】 Define Your Meter. あなたのシステムのメーターを定義すべし︕
Chapter3 - Optimize 法則その07 Unchallenged Success Leads to Assumptions （異論のない成功は過信のキッカケ）
エネルギー効率のいいプログラミング⾔語ランキング 引⽤: Ranking programming languages by energy efficiency - Rui Pereira, INESC Tech 64
エネルギー効率のいいプログラミング⾔語ランキング 50倍以上燃費効率が悪い 引⽤: Ranking programming languages by energy efficiency - Rui Pereira, INESC Tech 65
Cost Optimized = More Sustainable（再掲） 66
“僕らはずっとこうやってきたから”を疑え 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 67
Chapter3 - Optimize 法則その07 Unchallenged Success Leads to Assumptions （異論のない成功は過信のキッカケ） 【Takeaway】 Disconfirm Your Beliefs. あなたの信念を否定しなさい ︕
まとめ 1. ビジネスに即した設計をすべし 2. 監視されていないシステムは未知のコストを⽣む 3. 異論のない成功は過信のキッカケ 69
Thank You for Listening！ カジュアル⾯談、絶賛募集中〜 The Frugal Architect、こちらから読めます︕ We are Hiring ! https://recruit.fusic.co.jp/