AWS研修　パブリッククラウドの活用

Transcript

1. パブリッククラウドの活⽤ 株式会社リクルート クラウドアーキテクトG

2. ⽬次 • 旧来型ITリソース利⽤の課題 • パブリッククラウド活⽤によって得られるメリット • 他覚えておいてほしいこと • まとめ 2

3. 注意 ここで述べていることは⼀般論なので、 必ずしもすべてで正となるとは限りません、 状況によって変わることはありうることを覚えておいてください。 3

4. 旧来型ITリソース利⽤の課題 4

5. 旧来型ITリソース利⽤の課題 われわれ(≒ リクルート)がやりたいことはなんだろう ? 5

6. 旧来型ITリソース利⽤の課題 われわれ(≒ リクルート)がやりたいことはなんだろう︖ 6 カスタマー・クライアントに価値を最短・最安で提供すること

7. 旧来型ITリソース利⽤の課題 カスタマー・クライアントへの価値提供という観点で考える と、旧来型のITリソースには課題がいくつか存在する。 • 各種ファシリティの確保・維持 • リソース柔軟性の確保 7

8. 旧来型ITリソース確保の課題 カスタマー・クライアントへの価値提供という観点で考える と、旧来型のITリソースには課題がいくつか存在する。 • 各種ファシリティの確保・維持 • リソース柔軟性の確保 8

9. 旧来型ITリソース利⽤の課題(各種ファシリティの確保・維持) 9 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ ・ネットワーク ミドルウェア アプリケーション

   プロダクト・サービス

10. 旧来型ITリソース利⽤の課題(各種ファシリティの確保・維持) 10 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ ・ネットワーク ミドルウェア アプリケーション

    プロダクト・サービス カスタマー・クライアントに 直接的な価値を届けているのはここ

11. 旧来型ITリソース利⽤の課題(各種ファシリティの確保・維持) 11 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ ・ネットワーク ミドルウェア アプリケーション

    プロダクト・サービス 探す & 契約・購⼊ 設計 & 建設 設計 & 機材選定 & 導⼊ 設計 & 機材選定 & 導⼊ 要件定義 & ハードウェア機器選定 & 導⼊

12. 旧来型ITリソース利⽤の課題(各種ファシリティの確保・維持) 12 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ ・ネットワーク ミドルウェア アプリケーション

    プロダクト・サービス 従来の形ですべてをイチからやろう とするととにかく時間がかかる 探す & 契約・購⼊ 設計 & 建設 設計 & 機材選定 & 導⼊ 設計 & 機材選定 & 導⼊ 要件定義 & ハードウェア機器選定 & 導⼊

13. 旧来型ITリソース利⽤の課題(各種ファシリティの確保・維持) 13 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ ・ネットワーク ミドルウェア アプリケーション

    プロダクト・サービス 実際にはプロダクト・サービスとして 必要な各種要件を満たせるのであれば 何でも良くなる (この傾向は下に⾏くほど強くなる) ≒ 要件が満たせるなら早くて安いのが正義

14. 旧来型ITリソース利⽤の課題(各種ファシリティの確保・維持) 14 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ ・ネットワーク ミドルウェア アプリケーション

    プロダクト・サービス 可能な限りこちらに注⼒ 可能な限り低コストかつ短期間で作り上げたい

15. 旧来型ITリソース利⽤の課題(各種ファシリティの確保・維持) 15 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ ・ネットワーク ミドルウェア アプリケーション

    プロダクト・サービス 可能な限りこちらに注⼒ 新規で何かを始めようとする場合や 追加する場合は少なくともこのあたりは必要になる

16. 旧来型ITリソース利⽤の課題(各種ファシリティの確保・維持) 16 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ ・ネットワーク ミドルウェア アプリケーション

    プロダクト・サービス 可能な限りこちらに注⼒ 新規で何かを始めようとする場合や 追加する場合は少なくともこのあたりは必要になる 申請書を頑張って書くお仕事

17. 旧来型ITリソース利⽤の課題(各種ファシリティの確保・維持) 17 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ ・ネットワーク ミドルウェア アプリケーション

    プロダクト・サービス 可能な限りこちらに注⼒ 新規で何かを始めようとする場合や 追加する場合は少なくともこのあたりは必要になる 申請書を頑張って書くお仕事 組織をまたいで申請 & 承認 結果、数⽇〜数ヶ⽉かかってしまう

18. 旧来型ITリソース利⽤の課題(各種ファシリティの確保・維持) 18 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ ・ネットワーク ミドルウェア アプリケーション

    プロダクト・サービス 可能な限りこちらに注⼒ 新規で何かを始めようとする場合や 追加する場合は少なくともこのあたりは必要になる 申請書を頑張って書くお仕事 組織をまたいで申請 & 承認 結果、数⽇〜数ヶ⽉かかってしまう とにかく時間がかかりすぎる

19. 旧来型ITリソース利⽤の課題 カスタマー・クライアントへの価値提供という観点で考える と、旧来型のITリソースには課題がいくつか存在する。 • 各種ファシリティの確保・維持 • リソース柔軟性の確保 19

20. リソース柔軟性の確保 リソースの柔軟性が低い 20

21. リソース柔軟性の確保 リソースの柔軟性が低い リソースの構成変更を短期間かつ容易に実⾏できない 21

22. リソースの構成変更を短期間かつ容易に実⾏できない 旧来型のリソース確保の⽅法では、利⽤要求に対して 1. 過剰なハードウェアリソースを確保 Ÿ コストが余分にかかり続けることになる 2. リソースの不⾜を許容する Ÿ ビジネスにおける機会損失に直結

    22 リソースの不⾜を許容 機会損失 ビジネス遂⾏のために 必要なリソース 過剰な投資 リソース 時間

23. リソースの構成変更を短期間かつ容易に実⾏できない 旧来型のリソース確保の⽅法では、利⽤要求に対して 1. 過剰なハードウェアリソースを確保 Ÿ コストが余分にかかり続けることになる 2. リソースの不⾜を許容する Ÿ ビジネスにおける機会損失に直結

    23 リソースの不⾜を許容 機会損失 ビジネス履⾏のために 必要なリソース 過剰な投資 過剰投資 or 機会損失 の⼆者択⼀を迫られがち

24. 旧来型ITリソース利⽤の課題 ① プロダクト、サービスを通して価値提供をするまでに時間がかかりすぎる ② 過剰投資 or 機会損失の2者択⼀を迫られがち 24

25. 旧来型ITリソース利⽤の課題 ① プロダクト、サービスを通して価値提供をするまでに時間がかかりすぎる ② 過剰投資 or 機会損失の2者択⼀を迫られがち 25 ※ もちろんですが、他にもいろいろな課題が存在します

26. パブリッククラウド活⽤によって得られるメリット 26

27. 旧来型ITリソース利⽤の課題(再掲) ① プロダクト、サービスを通して価値提供をするまでに時間がかかりすぎる ② 過剰投資 or 機会損失の2者択⼀を迫られがち 27 パブリッククラウドを活⽤することで ある程度解決を図ることができます

28. 旧来型ITリソース利⽤の課題(再掲) ① プロダクト、サービスを通して価値提供をするまでに時間がかかりすぎる ② 過剰投資 or 機会損失の2者択⼀を迫られがち 28

29. プロダクト、サービスを通して価値提供をするまでに時間がかかりすぎる • ⼀般にパブリッククラウドはアカウントさえ準備すれば⼀通りの機能を使うこと が可能です。 29 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ

    ・ネットワーク ミドルウェア アプリケーション プロダクト・サービス ある程度までは パブリッククラウド側で 準備 & 管理してくれます

30. プロダクト、サービスを通して価値提供をするまでに時間がかかりすぎる • ⼀般にパブリッククラウドはアカウントさえ準備すれば⼀通りの機能を使うこと が可能です。 30 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ

    ・ネットワーク ミドルウェア アプリケーション プロダクト・サービス ある程度までは パブリッククラウド側で 準備 & 管理してくれます (責任共有モデル)

31. プロダクト、サービスを通して価値提供をするまでに時間がかかりすぎる • ⼀般にパブリッククラウドはアカウントさえ準備すれば⼀通りの機能を使うこと が可能です。 31 ⼟地 建物 ラック 空調・電源 サーバー・ストレージ

    ・ネットワーク ミドルウェア アプリケーション プロダクト・サービス 我々はこの部分に注⼒できます

32. 責任共有モデル • AWSとAWS利⽤者の間での各種管理をどちらが⾏うかというモデル • https://aws.amazon.com/jp/compliance/shared-responsibility-model/ • AWSにおけるマネージドな度合いが⾼いほど、AWS利⽤者がやらなければいけ ないことは少なくなる (＝要件を満たせる限りはマネージド・サービスに寄せたほうがお得) 32

    AWSを利⽤しない場合、 ⾃前で管理しなければ⾏けない部分

33. GUIやAPIを介した操作 • GUIやAPIを介して操作することで効率的にリソースを構成することができます • これによって単⼀のプロダクトチーム内で⾃律的に実⾏できる範囲が広がります。 33 旧来型の進め⽅※ パブリッククラウドをつかった進め⽅ インフラ管理者 プロダクトチーム

    申請書ベースで依頼&構築 プロダクトチーム AWS Cloud GUI(ブラウザ) ・APIベースで構築 24/365で依頼し続けても問題なし ⽣⾝の⼈間なので限度あり ※ パブリッククラウドと同様の仕組みを作ることも可能だがコストや仕組みづくりのための要求スキルが⾼くなる

34. 旧来型ITリソース利⽤の課題(再掲) ① プロダクト、サービスを通して価値提供をするまでに時間がかかりすぎる ② 過剰投資 or 機会損失の2者択⼀を迫られがち 34

35. 過剰投資 or 機会損失の2者択⼀を迫られがち • パブリッククラウドプロバイダでは⼤量のリソースをあらかじめ確保しています • 利⽤者はプロバイダが保有するリソースをから必要量を切り出して利⽤します • 利⽤しただけの料⾦を⽀払います(従量課⾦, Pay

    as you go) 35 巨⼤な リソースプール 必要な分だけを 切り出して利⽤ お 借 り し ま す

36. 過剰投資 or 機会損失の2者択⼀を迫られがち • パブリッククラウドプロバイダでは⼤量のリソースをあらかじめ確保しています • 利⽤者はプロバイダが保有するリソースをから必要量を切り出して利⽤します • 利⽤しただけの料⾦を⽀払います(従量課⾦, Pay

    as you go) 36 巨⼤な リソースプール 必要な分だけを 切り出して利⽤ お 借 り し ま す パブリッククラウドプロバイダの提供 するサービスやAPIでスケールの変更 を⾃動化することも可能

37. 過剰投資 or 機会損失の2者択⼀を迫られがち • パブリッククラウドプロバイダでは⼤量のリソースをあらかじめ確保しています • 利⽤者はプロバイダが保有するリソースをから必要量を切り出して利⽤します • 利⽤しただけの料⾦を⽀払います(従量課⾦, Pay

    as you go) 37 巨⼤な リソースプール 必要な分だけを 切り出して利⽤ お 借 り し ま す パブリッククラウドプロバイダの提供 するサービスやAPIでスケールの変更 を⾃動化することも可能 必要最⼩限のリソースのみを確保する ことで料⾦を圧縮可能

38. 過剰投資 or 機会損失の2者択⼀を迫られがち • パブリッククラウドプロバイダでは⼤量のリソースをあらかじめ確保しています • 利⽤者はプロバイダが保有するリソースをから必要量を切り出して利⽤します • 利⽤しただけの料⾦を⽀払います(従量課⾦, Pay

    as you go) 38 巨⼤な リソースプール 必要な分だけを 切り出して利⽤ お 借 り し ま す パブリッククラウドプロバイダの提供 するサービスやAPIでスケールの変更 を⾃動化することも可能 必要最⼩限のリソースのみを確保する ことで料⾦を圧縮可能 必要なリソースを容易に確保できます

39. スケールアウト・スケールインによるリソースの制御 必要なリソースをAWSの提供するサービス(Auto Scalingなど)のAPIを介して 準リアルタイムに確保できるようにすることで、 リソースの過不⾜を最⼩化することができます 39 スケールアウト、スケールインの 適切な利⽤によるコスト最適化 ビジネス遂⾏のために 必要なリソース

    リソース 時間

40. スケールアウト・スケールインによるリソースの制御 必要なリソースをAWSの提供するサービス(Auto Scalingなど)のAPIを介して 準リアルタイムに確保できるようにすることで、 リソースの過不⾜を最⼩化することができます 40 スケールアウト、スケールインの 適切な利⽤によるコスト最適化 ビジネス遂⾏のために 必要なリソース

    リソース 時間 リソースの過不⾜を最⼩化することで、 コスト最適化を実現できます

41. ここまでの内容は課題への緩和策としてのメリット （ネガティブな部分の解決） ここからはパブリッククラウドを使うことによる ポジティブな⾯を⾒てみます 41

42. パブリッククラウドの活⽤によるメリット • 機能⾯のメリット • ⾮機能⾯のメリット 42

43. パブリッククラウドの活⽤によるメリット • 機能⾯のメリット • ⾮機能⾯のメリット 43

44. 機能⾯のメリット 新機能が⽇々リリースされており、できることが増えていく AWSでは⼀⽇あたり複数の新機能がリリース & re:Inventなどのイベント期間中 はさらに⼤量の新機能がありリースされる 44

45. 機能⾯のメリット 新規の機能が続々とリリースされることで、 現実的なコストで実現できることが⽇々増えていく 45 今⽇実現できる範囲 明⽇実現できる範囲 ※ ただし古くなったものなどについてはEOLが発⽣しバージョンアップなどの対応が必要になる。 (これは旧来からのハードウェア・ソフトウェアのEOLと同じ)

46. パブリッククラウドの活⽤によるメリット • 機能⾯のメリット • ⾮機能⾯のメリット 46

47. ⾮機能⾯のメリット • コスト削減 • 過去10年間に81回以上の値下げ https://aws.amazon.com/jp/blogs/news/category/price-reduction/ • 細かい単位での課⾦(最⼩1ミリ秒での課⾦) • ⾼いレベルの⾮機能要件実現

    • リージョンとアベイラビリティゾーンを⽤いた可⽤性の向上(地理的な可⽤性の向上) 47

48. ⾮機能⾯のメリット • コスト削減 • 過去10年間に81回以上の値下げ https://aws.amazon.com/jp/blogs/news/category/price-reduction/ • 細かい単位での課⾦(最⼩1ミリ秒での課⾦) • ⾼いレベルの⾮機能要件実現

    • リージョンとアベイラビリティゾーンを⽤いた可⽤性の向上(地理的な可⽤性の向上) 48 複数拠点にバックアップを持つことや複数拠点で データをミラーし冗⻑性を保ちつつサービスを提供 するといったことが個⼈レベルでも実現可能

49. リージョン • 世界各地にリージョンとして分離された環境を提供し、それぞれの障害が他の リージョンに可能な限り影響しないよう管理されています • リージョンの内部で更にアベイラビリティゾーンが確保されています 49

50. アベイラビリティゾーン(AZ, 可⽤性ゾーン) • リージョンを構成する1つ以上のデータセンター • 冗⻑的な電⼒源・ネットワークを持つ • AZ間は低レイテンシなネットワークで接続されている 50

51. まとめ • パブリッククラウドを活⽤することでより短期間かつ安価にサービスを提供でき る可能性について説明しました。 • 従来では個⼈やチームレベルでは実現が困難だった事柄についてもパブリックク ラウドの仕組みを活⽤することで実現可能になることについて解説しました。 51

52. リージョンとアベイラビリティゾーンに関しての参考資料 • 「リージョンとアベイラビリティーゾーン」 • https://aws.amazon.com/jp/about-aws/global- infrastructure/regions_az/ • アベイラビリティーゾーンを使⽤した静的安定性 • https://aws.amazon.com/jp/builders-library/static-stability-using-

    availability-zones/ 52