multi cloud design pattern(beta)
TRANSCRIPT
Masashi Terui @ marcy_teruiI’m a developer and a architect in a operators company (JIG-SAW Inc.)
I’m interested in Cloud, Automation, IoT(Server Side) and more. I’m a AWS Certified DevOps Engineer Professional.
I’m a husband of my wife. I’m a father of my son and my daughter.
ABOUT ME
2
3
4
ABOUT US
5
Coming soon!!
6
CDPって知ってますか？
WHAT IS CDP?
7
AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを
使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方
法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。
これまで多くのクラウドアーキテクト達が発見してきた、もしくは編み出しきた設計・運用のノウハウ
のうち、クラウド上で利用が可能なものをクラウドデザインのパターンという形式で一覧化し、暗黙知
から形式知に変換したものであるといえる。 – AWS-CloudDesignPattern Wiki (http://aws.clouddesignpattern.org/) より –
”
色々あります
8
58パターン
http://aws.clouddesignpattern.org/
34パターン
https://msdn.microsoft.com/en-us/library/dn568099.aspx
48パターン
http://www.gg-web.jp/document/DesignPattern/
2015.07.27時点 俺調べ 他にあったら教えてください
9
どれも知見が溢れていて 素晴らしいですよね:-)
10
でも、思うんです
11
単一のクラウドに閉じる必要あります？
12
組み合わせることだってできますよね？
13
若干、厳しみのあるパターンとかありますよね？ それ、他のクラウド使えば良い感じになりません？
14
より良いシステムを作れるなら
15
一つのクラウドに拘る必要はない
16
なにより
ワクワクしません？
17
2015.07.27時点 俺調べ 事業者によって粒度が違うので参考程度
45サービス56サービス 19サービス ？サービス
19
例えば
20
足りないものを補う
21
No VM Scheduled Job
AzureのマネジメントサービスであるJob SchedulerのHTTP Request機能を使い、 AWSのAPI Gatewayにリクエストを飛ばしてLambda Functionを起動することで、
EC2やAzure VMを一切使わずに定時処理を行う。
22
特徴を踏まえて使い分ける
23
Enhanced Scaling
VM*1、ロードバランサ*2のスケーリングに優れたGCPでオンライン処理、 マネージドのジョブキューを持ち、Spot Instanceで費用を抑えられるAWSでバッチ処理を行う。
*1) Google Compute Engine Autoscaler発表。わずか数分で千インスタンスをスケーラブルに伸縮(http://www.publickey1.jp/blog/14/google_compute_engine_autoscaler.html) *2) GoogleのHTTPロードバランサーの破壊力があり過ぎる(http://qiita.com/kazunori279/items/8d2417c8510021c697e7)
24
課金体系の違いを活かす
25
Low Cost High Availability CDN
平常時は転送量課金が安い（というか無料） 国内クラウドからコンテンツ配信しつつ、 Route53のDNSフェイルオーバーでお手軽冗長化。 フェイルオーバー先及びコンテンツのマスターは、 堅牢性に定評のあるS3とする。
利用シーン • スモールスタートな画像・動画配信系サイトなど • 大容量コンテンツへのアクセス集中時の一時的処置 ※大きくなったらちゃんとお金を払ってCDN使うべき ※普通のサイトは平常だと転送量課金 < VM代金となる可能性有り
26
最近わりとよく聞くやつ
27
BigQuery for now
とりあえず、BigQueryに突っ込んどけば簡単に分析が初められる。 無理してEMR,HD Insight,Redshiftとか使わなくて良い。
若干意味合いが違いますが、一つに拘ると損をする典型例として。
28
他にもアイデアレベルでは色々 （未実証なのでここでは言いませんが）
29
パターンを考える時の ポイントや注意事項
ポイント や
注意事項
30
• 基本は同一クラウド内で解決できるかどうかを考える
• むやみに色々使うと管理コストが上がる
• レイテンシを考慮する
• 経路の暗号化は必須
• 転送量課金があることを念頭に置く
• ただ、データのみのやりとりだと意外と転送量課金は気にならないレベル
31
Multi Cloudを実現するために
実現のために
32
• 部分的な適用の場合はあまり気にしなくて良い
• フルに活用するためには管理コストを抑えることや、
必要に応じてマイグレーションできるようにしておく必要がある
→そもそも疎結合な作りにしておく
→再現性のあるインフラ≒Infrastructure as Code
33
そして、一番大事なこと
Most Important
34
動きの速いクラウドについて全てを熟知することは難しい。
実際もっと色々あるはずだけど、把握しきれていない。
アイデアがあっても中々実証レベルにたどり着かないこともある。
だけど、もっと色々な素敵なパターンがあるはず。
だから、皆でシェアしましょう。
35
しかし、同じやり方だと問題がある ※ユーザベースでやるためにはという話
問題点（私感）
36
• 新パターンの提案の敷居が高い
• 採用プロセスが不透明
• 管理者が決まっているので、管理者のモチベーションや忙しさに依存
• というか、事業者サイドで握っててユーザが入り込む余地がない？(AWS以外)
37
そこで
38
提案
39
ユーザによるユーザのための集合知
41
Pull RequestとIssueを使った 透明性のある情報共有を
Rule(案)
42
• 新パターンの提案や修正はPull Requestにて行う
• 公平性を期すため、一度パターンが採用された人にはコミット権付与
• 古くなったパターンなどはIssueで議論の上削除・修正
• 最低限、実証済みのパターンのみを登録する
• 特定の事業者を貶めるような内容はNG
43
お願い
44
デザインとか誰か・・・
45
AWS,Azure以外の事業者様、 Cacooにアイコンを・・・
46
何卒、よろしくお願いしますm(_ _)m
まとめ
47
• CDPは偉大
• でも、垣根を越えればもっと素敵なパターンが有るはず
• ユーザによるユーザのための集合知を
• 透明性のあるプロセスで
• 協力待ってます:-)
48
最後にちょっとだけ
49
1.MCDP(仮)の実践したい方 2.イケてるクラウドインフラ上で IoTサーバサイド開発したい方 (主にPython, 一部Go, C++)
勤務地は東京 or 札幌で選べます。 ちなみに私的には２の方が重要ｗ
