231209 Shinshin TechLive 登壇資料

569 Views

December 12, 23

スライド概要

profile-image

福岡を拠点に、Webシステム開発をはじめとし、AI・IoTといった最先端技術を用いた開発、クラウドインフラ(AWS)、コンサルティングサービス、複数の自社プロダクトの提供を行う会社です。100%自社開発にこだわり、他にはない自由な発想・提案で、お客様の事業の成長に貢献しています。「人に多様な道を 世の中に爪跡を」という存在意義を掲げ、今後より成長すべく邁進しています。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

資格9冠ビジネス職 Notion Ambassador 帰国⼦⼥からみたre:Invent 11th of Dec 2023, at Fusic TechLive Vol.17 1

2.

⾃⼰紹介 Role at Fusic Skill Shinshin a.k.a., ・むろいくん ・シンくん ・Shaigne (English Name) § § 事業推進部⾨チームAWS所属 AWSセールス、コンサルタント、ソリューションアーキ テクト、チーム海外、英語の⼈、ガヤガヤ § AWS § § 英語(学⽣時代イギリス) Notion Ambassador § § Github︓Shinshin1313 X(旧Twitter)︓@shin13fs6x SNS 2

3.

たくさんおもいで 3

4.

たくさんおもいで 4

5.

たくさんおもいで 5

6.

たくさんおもいで 6

7.

たくさんおもいで 7

8.

たくさんおもいで 8

9.

たくさんおもいで 9

10.

たくさんおもいで 10

11.

たくさんおもいで 11

12.

喋る内容、結構悩んだ 海外Techな話いいなー 量⼦コンピューターいいなー Amazon Qでもありだなー 12

13.

悩んだ結果 まようなー、まようなー 13

14.

Warner VogelsのKeynoteがいいvibesだった なんかちょっと哲学チック 私、⼤学で哲学を専攻 古代ギリシャ哲学から現代の倫理哲学までざっくりやったYO︕ 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 14

15.

Warner VogelsのKeynoteがいいvibesだった なんかちょっと哲学チック 私、⼤学で哲学を専攻 ! ! ! … い な か し る や 古代ギリシャ哲学から現代の倫理哲学までざっくりやったYO︕ 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 15

16.

Warner Veglsʼ Keynoteより︕ The Frugal Architectを振り返る︕︕︕ 11th of Dec 2023, at Fusic TechLive Vol.17 16

17.

Who is Warner Vogels? ワーナー・ハンズ・ピーター・ヴォゲルス (Werner Hans Peter Vogels、1958年10 ⽉3⽇ - )はAmazon.comの最⾼技術責任者 兼副社⻑であり、社内での技術⾰新の推進を 担当している。 2008年にヴォゲルスがアマゾンのクラウド コンピューティング事業に進出したAmazon Web Services (AWS)の影にいる設計者の⼀ ⼈だということが明らかになった。 その年の間に、ヴォゲルスは切れ⽬なくクラ ウドコンピューティングとAWSとそれらの 業界へのメリットを売り込み続けた。 引⽤: Wikipedia 17

18.

The Frugal Architect Points!!! q コストを念頭に置いたArchitecting(設計)思想 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 18

19.

The Frugal Architect Points!!! q コストを念頭に置いたArchitecting(設計)思想 q Cost-Awareな設計は現代における失われた美学 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 19

20.

The Frugal Architectの誕⽣の背景 オンプレ時代 - クラウド到来 必要なサーバー・ディスクスペック ネットワーク機器 サーバールーム設置・レンタル代⾦ 光熱費・保守⼈員費⽤ を、向こう数年のスケールを予測して設計 クラウド時代 - 固定費⽤がかからず - APIリクエストベースでのその都度課⾦ - 柔軟に課⾦ペースを調整できる とりあえず動かしみて、課⾦を計れるよう になった 20

21.

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

22.

7つの法則 Design 1. コストを⾮機能要件の1つとして考えよ 2. ビジネスに即した設計をすべし 3. 設計は常にトレードオフだ Measure 4. 監視されていないシステムは未知のコストを⽣む 5. コストを意識したアーキテクチャーはコスト管理を実践している Optimize 6. コストの最適化は段階的である 7. 異論のない成功は過信のキッカケ 22

23.

7つの法則 Design 1. コストを⾮機能要件の1つとして考えよ 2. ビジネスに即した設計をすべし 3. 設計は常にトレードオフだ Measure 4. 監視されていないシステムは未知のコストを⽣む 5. コストを意識したアーキテクチャーはコスト管理を実践している Optimize 6. コストの最適化は段階的である 7. 異論のない成功は過信のキッカケ 23

24.

法則の紹介に⼊る前に︕

25.

Cost Optimized = More Sustainable 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 25

26.

サステナビリティ例(DynamoDBの場合) 顧客 1回だけ読む(返されるValueが最新じゃない可能性がある) AWS Cloud 1. Consistent Read Amazon DynamoDB 2. Strongly Consistent Read Virtualization(仮想化) 2回読む(より最新のValueが返される) AWS Data Centres 26

27.

サステナビリティ例(DynamoDBの場合) 顧客 - 物理サーバーに負荷がかかりやすい(よりCPUを使う) - ⾦額がConsistent Readの倍 AWS Cloud 1. Consistent Read Amazon DynamoDB 2. Strongly Consistent Read Virtualization(仮想化) 2回読む(より最新のValueが返される) AWS Data Centres 27

28.

サステナビリティ例(DynamoDBの場合) サステナブルじゃない…!!! 顧客 - 物理サーバーに負荷がかかりやすい(よりCPUを使う) - ⾦額がConsistent Readの倍 AWS Cloud 1. Consistent Read Amazon DynamoDB 2. Strongly Consistent Read Virtualization(仮想化) 2回読む(より最新のValueが返される) AWS Data Centres 28

29.

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

30.

Cost Optimized = More Sustainable 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 30

31.

7つの法則 Design 1. コストを⾮機能要件の1つとして考えよ 2. ビジネスに即した設計をすべし 3. 設計は常にトレードオフだ Measure 4. 監視されていないシステムは未知のコストを⽣む 5. コストを意識したアーキテクチャーはコスト管理を実践している Optimize 6. コストの最適化は段階的である 7. 異論のない成功は過信のキッカケ 31

32.

Chapter1 - Design 法則その02 Systems that Last Align Cost to Business (ビジネスに即した設計をすべし)

33.

ビジネスの収益と、技術設計は⼀致すべき 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 33

34.

ある通信事業者の例 GBの利⽤量で収益を上げるモデルなのに、無闇に無制限使い放題を 導⼊しちゃった場合 Capped Model(定額GB制) 利益 Unlimited(無制限使い放題) ⾚字 30GB 20GB 10GB 予期せぬ消費者⾏動の変化 34

35.

ある通信事業者の例 GBの利⽤量で収益を上げるモデルなのに、無闇に無制限使い放題を 導⼊しちゃった場合 Capped Model(定額GB制) Unlimited(無制限使い放題) は り 売 安 の 術 技 い な さ 即 ⾚字 に ク ッ 利益 ジ ロ ジネス ︕ ビ る め 絞 を ⾸ 30GB ⾃分の 20GB 10GB 予期せぬ消費者⾏動の変化 35

36.

AWS Lambdaも最初はそうだった(︕︖) 引⽤: https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ 36

37.

サービスリリース当初の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

38.

サービスリリース当初の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

39.

問題点① 顧客数のスケール 顧客 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

40.

問題点② 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

41.

細分化することにより、各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

42.

ビジネスロジックをFollowするアーキテクチャーへ進化させた 当初のLambda 現代のLambda Firecracker導⼊ - t2インスタンス数単位でしかLambda環境を作れなかった (=顧客のスケールに対応が難しかった) - 各インスタンスのCPU使⽤率が安定しなかった (=効率的なリソース利⽤と、ビジネス収益化ができなかった) - MicroVMsの導⼊により各ホスト環境の効率化に成功 - More Lambda Functions, More Customersを実現 - 効率的なリソース利⽤により、ビジネス収益を実現 42

43.

Chapter1 - Design 法則その02 Systems that Last Align Cost to Business (ビジネススケールに即した設計をすべし) 【Takeaway】 Build Evolvable Architecture. ビジネスモデルに即した、進化し続ける設計を続けなさい︕

44.

Chapter2 - Measure 法則その04 Unobserved Systems Lead to Unknown Costs (監視されていないシステムは未知のコストを⽣む)

45.

Amsterdumでの電⼒消化事情 同じような建物でも、建物によって電⼒消化が異なる → 何故︖︖︖ 45

46.

Amsterdumでの電⼒消化事情 地下にブレーカーがある建物 = 電⼒消化に気付きずらい More Cost More Cost More Cost 46

47.

Amsterdumでの電⼒消化事情 地下にブレーカーがある建物 = 電⼒消化に気付きずらい More Cost More Cost ︕ る え 整 More Cost を 境 環 る き で 析 分 ・ 知 検 に 切 適 を ト コス 47

48.

Amazon.comのCost Metrics Transitive Cost/Request (アプリ/システムレベル) Cost/Request (マイクロサービスレベル) Conversion Cost/Request (サービスレベル) 48

49.

Amazon.comのCost Metrics Transitive Cost/Request (アプリ/システムレベル) ただ、いう っ 化 視 可 の てもここ 〜 ね よ す で て難しい Cost/Request (マイクロサービスレベル) Conversion Cost/Request (サービスレベル) 49

50.

NEW!!! AWS Management Console myApplications 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 50

51.

NEW!!! AWS Management Console myApplications 、 ん せ ま り ︕ お ︕ て ︕ れ ん 触 せ だ ま ま い ざ ご 訳 申し 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 51

52.

NEW!!! AWS Management Console myApplications 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 52

53.

NEW!!! AWS Management Console myApplications 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 53

54.

NEW!!! AWS Management Console myApplications 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 54

55.

NEW!!! AWS Management Console myApplications 引⽤: https://aws.amazon.com/blogs/aws/new-myapplications-in-the-aws-management-console-simplifies-managing-your-application-resources/ 55

56.

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

57.

NEW!!! Amazon CloudWatch Application Signals 引⽤: https://aws.amazon.com/blogs/aws/amazon-cloudwatch-application-signals-for-automatic-instrumentation-of-your-applications-preview/ 57

58.

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

59.

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

60.

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

61.

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

62.

Chapter2 - Measure 法則その04 Unobserved Systems Lead to Unknown Costs ( 監視されていないシステムは未知のコストを⽣む ) 【Takeaway】 Define Your Meter. あなたのシステムのメーターを定義すべし︕

63.

Chapter3 - Optimize 法則その07 Unchallenged Success Leads to Assumptions (異論のない成功は過信のキッカケ)

64.

エネルギー効率のいいプログラミング⾔語ランキング 引⽤: Ranking programming languages by energy efficiency - Rui Pereira, INESC Tech 64

65.

エネルギー効率のいいプログラミング⾔語ランキング 50倍以上燃費効率が悪い 引⽤: Ranking programming languages by energy efficiency - Rui Pereira, INESC Tech 65

66.

Cost Optimized = More Sustainable(再掲) 66

67.

“僕らはずっとこうやってきたから”を疑え 引⽤: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels 67

68.

Chapter3 - Optimize 法則その07 Unchallenged Success Leads to Assumptions (異論のない成功は過信のキッカケ) 【Takeaway】 Disconfirm Your Beliefs. あなたの信念を否定しなさい ︕

69.

まとめ 1. ビジネスに即した設計をすべし 2. 監視されていないシステムは未知のコストを⽣む 3. 異論のない成功は過信のキッカケ 69

70.

Thank You for Listening! カジュアル⾯談、絶賛募集中〜 The Frugal Architect、こちらから読めます︕ We are Hiring ! https://recruit.fusic.co.jp/