jawsdays 2017 新訳-とある設計士の雲設計定石目録_3
23
#jawsdays #jd2017_a
Transcript of jawsdays 2017 新訳-とある設計士の雲設計定石目録_3
#jawsdays #jd2017_a
#jawsdays #jd2017_a
自己紹介氏名：金平晃尚職業：フリーランス（ 2016 年 3 月末～）得意：インフラ、データベース、プログラミング好きな言語： Java, Python好きな AWS サービス： Lambda, EMRJAWS ： CLI 専門支部、アーキテクチャ専門支部、ビッグデータ支部AWS ： 2016/6 から本格使用開始、 2016/12 Re:Invent 自費参加資格： Since 2017/03/09( 木 )
#jawsdays #jd2017_a
今日のお話の全体構成図
Office
Direct Connect
VPN connection
Cloud Front
Route 53
RDS DB instance
RDS DB instance standby
(multi-AZ)
AWS Directory Service
Amazon API Gateway
AmazonCognito
AWSLambda
AmazonDynamoDB
AmazonS3
AMI
Auto Scaling
EC2
Amazon Provided
DNS
EC2
Stagingserver
Prodserver
Prodserver
Bastionserver
corporate data center
EC2
Elastic Load Balancing
EC2
DNS Server
#jawsdays #jd2017_a
マイクロサービスアーキテクチャ (1/2)
EC2, RDS で作る 3 層構成はオンプレから比較的簡単に移行できるパターンでも維持費はけっこうかかるので対策したい
１．リザーブド / スポットインスタンスを使ったり 処理のピークに合わせてスケールさせる２．使った分だけ支払いの AWS マネージドサービスを活用する EC2 ： 1 時間単位の料金設定 Lambda ： 100 ミリ秒単位の料金設定 マイクロサービスアーキテクチャと相性がいい
#jawsdays #jd2017_a
マイクロサービスアーキテクチャ (2/2)
一枚岩（モノリシック）な大きなシステムを作りこむのでなく、小さなサービスを組み合わせてシステムを作る特徴 効果サービス単位の組織 意思疎通しやすい規模サービス間は疎結合で外部インターフェース間でのみ通信
内部実装はチームごとに自由に作れるバージョンアップも単独実施可能
サーバに状態を持たないステートレス、イミュータブル
環境の複製、再作成が簡単必要なサービスだけスケールできる
各サービスの実装は比較的簡単 単体テストは易しい総合テストは難しい
処理の自動化 コード修正後勝手にテストなど早いリリースサイクルを実現
#jawsdays #jd2017_a
マネージドサービスの活用 (1/2)
マネージドサービスへの置き換え
特徴と対応EC2 ⇒ Lambda 最大メモリ 1.5GB 。最大処理時間 5 分。 3 回リトライ。
まれに発火しないときがある。何度実行しても同じ結果を返すように実装すること。
EBS ⇒ S3 大容量のストレージ。結果整合性。安い。データをローカルに持ってくるところからはじめる。
RDS ⇒ DynamoDB
スループット保証の KVS 。札束でたたくと強くなる。トランザクションは自前での実装が必要。
監視 ＝ CloudWatch 総合テストが難しいのは流れを見失いがちなため。トランザクション ID を取りまわすなど工夫を。新サービス X-Ray が解決してくれるかもしれない。
AWS X-Ray
#jawsdays #jd2017_a
マネージドサービスの活用 (2/2)
• 最適に活用すれば維持 / 管理コストが下げられる– 目的を達成する方法が複数ある– サービスが多すぎて最適な設計がわからない ⇒最適解は用途と規模と時代で変わるので、 持っているスキル・開発期間・リスク・リターンを考慮して適宜見直していく。 効果が高い部分から順番に対応していく。 既存システムの置き換えをやる前に 簡単な新規サービスで使ってみてノウハウを貯めるなど。 疎結合な設計なら部分的に見直せる。 汎用性の高いものは CDP にしていきたい。
#jawsdays #jd2017_a
解決したい課題１• サーバを使わずに動的な Web サービスを作りたい• 独自ドメインを使いたい• HTTP/2 を使いたい• 800GET/ 秒を超えるアクセスをさばきたい• ユーザを管理したい• コストを削減したい
#jawsdays #jd2017_a
Amazon Route 53
AWSLambda
AmazonDynamoDB
Amazon CloudFron
t
Amazon API Gateway
users AmazonCognito
AmazonS3
Cognito UserPools でユーザを管理認証した人だけ API Gateway にアクセス可能マルチデバイス / アカウント対応な実装も可能
静的なコンテンツは S3へ配置動的な処理は javascript のライブラリで通信
APIGateway＋ cognito認証パターン (1/2)
とりあえず認証だけ Cognito 使ってコンテンツは EC2 というのも可能
サーバレスで会員専用サイトを作るパターン
①②
③
④
ドメインは Route53 で管理
#jawsdays #jd2017_a
APIGateway＋ cognito認証パターン (2/2)
利点• ユーザ認証した人だけが API を実行できる• Facebook や twitter アカウントでのログオンも作れる （ Cognito Federated Identities ）• 各言語向け SDK があるのでバックエンドはアプリと共通化できる注意点• Cognito の UserPools を直接使うときと
Federated Identites を使うときで認証の書き方が違うのでハマりやすい
#jawsdays #jd2017_a
解決したい課題２• URLへの初回アクセス時にコンテンツを生成し、
2 回目以降は同じ内容のコンテンツを返したい例）• 検索キーワードを元にコンテンツを生成するなど事前処理が難しい場合• 対象データ量は膨大だけどアクセスされる URL が限定されているためディスク容量を節約したい場合• コンテンツ生成処理に API スロットリング制限があって生成の回数を減らしたい場合
#jawsdays #jd2017_a
AmazonS3
Amazon CloudFron
t
AWSLambda
users
Amazon Route 53
Amazon API Gateway
すべてのファイルをキャッシュしないカスタム設定ファイルがないとき (404) は生成処理へのリダイレクト (307) を返すリダイレクトルール必要なら仮のファイルを S3 に設置して時間稼ぎ
コンテンツ遅延生成パターン (1/2)
URLへの初回アクセス時にコンテンツを生成し、2 回目以降は同じ内容のコンテンツを返したいときのパターン
① ②
③本物のファイルはキャッシュ設定をつけた上で設置
#jawsdays #jd2017_a
コンテンツ遅延生成パターン (2/2)
利点• 大きいキャッシュを持つより安い注意点• CloudFrontはデフォルトでは307 Temporary Redirectでさえもキャッシュするのでカスタム設定が必要• キャッシュが必要なファイルには明示的にS3タグを指定• S3の低冗長化ストレージ (RRS)を使えばコスト削減？ 2016年12月以降、東京リージョンはRRSの方が高くなった。 というかシンガポール・ムンバイ・サンパウロ以外全部高い！Qiita記事 : http://qiita.com/kyane/items/7e093ed5b4478181b491
#jawsdays #jd2017_a
解決したい課題３• 時間のかかる重たい API の処理結果を受けて別の処理を走らせたい 処理が終わるのを数分間隔でポーリングしたい≒
例） 実店舗の在庫数とオンラインショップの在庫数を 合わせるために在庫ファイルをアップロードする
#jawsdays #jd2017_a
SQSAWSLambda
AWSLambda
時間のかかる処理が終わるまでポーリングするパターン
何かの Web サービス
AWSLambda
①重たいリクエスト ③ステータス確認のポーリング NG ：遅延 QUEUE に再度投入 OK ：結果を取得して次の処理へ
API 処理結果ポーリングパターン (1/4)
NG
OK
②遅延 QUEUE で数分後にポーリング
遅延は SQS で実現できそうだけどSQS はプル型のサービスなので Lambda は直接連携できない・・・・
？
#jawsdays #jd2017_a
SQSAWSLambda
AWSLambda
CloudWatchEvent （ linux でいうところの cron ）を使う
何かの Web サービス
AWSLambda
①重たいリクエスト ③ステータス確認のポーリング NG ：遅延 QUEUE に再度投入 OK ：結果を取得して次の処理へ
API 処理結果ポーリングパターン (2/4)
NG
OK
②遅延 QUEUE で数分後にポーリング
CloudWatch
Event (time-based)
⇒SQS は Get しても Queue の内容を全部取れない。 CloudWatch イベントは最小 1 分間隔。思ったよりさばけない。
#jawsdays #jd2017_a
AWS Elastic
BeanstalkSQSAWS
LambdaAWS
Lambda
ElasticBeanstalk の Worker を使う
何かの Web サービス
AWSLambda
①重たいリクエスト ③ステータス確認のポーリング NG ：遅延 QUEUE に再度投入 OK ：結果を取得して次の処理へ
API 処理結果ポーリングパターン (3/4)
NG
OK
②遅延 QUEUE で数分後にポーリング
Beanstalk の Worker は SQS のメッセージを処理する EC2上の Web サーバLambda を同期実行するだけの処理を書く
#jawsdays #jd2017_a
API 処理結果ポーリングパターン (4/4)
利点• ElasticBeanstalk は EC2 で実装するより手間がかからない （ SQS メッセージの削除、サーバの再起動）• Lambda を呼ぶだけなら Worker は t2.nano でバーストしないでいけた。
（東京オンデマンド $0.008/h ≒ $5.76/ 月、マルチ AZ考慮なら 2倍）• Worker に直接処理を書いた場合は NW か CPU がネックになるはず注意点• SQS の遅延は最大 15 分なのでそれ以上は小細工が必要
#jawsdays #jd2017_a
AWS Step Functions
これ Step Functions でよくね？
#jawsdays #jd2017_a
Step Functions とは (1/2)
• Re:Invent 2016 で発表された新サービス• Lambda などの処理を状態遷移図に従って動かせるようにしたもの• SWF のフローを JSON で書けるようにした感じ？• 料金は（実行回数でなく）状態遷移回数に依存
– $0.000025/ 状態遷移回数• API 実行回数はリージョン毎に制限されている
– 状況により緩和申請を検討– 同時実行数は 1,000,000 まで OK
Bucket Refill Rate/sec新規実行 100 回 2 回 / 秒Activity関連 1,000 回 10 回 / 秒
#jawsdays #jd2017_a
Step Functions とは (2/2)
Type 説明Task Lambda: プッシュ型実行
Activity: プル型実行Parallel すべての処理が完了したら次の状態へ。
並列度は動的には変更できないChoice 変数の値により次の状態を切り替える分岐Wait 指定した時間 or 日時まで待つ（最大 1 年）Pass 何もしないSucceed 正常終了Fail 異常終了
ステートマシン - 状態遷移図に従った動作 (Amazon State Language(JSON))で定義 )
#jawsdays #jd2017_a
API 処理結果ポーリングパターン (Step Functions版 )
1 回リトライすると遷移回数は 9 回。1,000ユーザのタスクを 1 時間に 1 回実行するケース• API制限そのままだと全部実行するには 1,800 秒かかる• 料金は
⇒1,000人ずつ処理する方式にすると $0.162 になるけど– Lambda のメモリ、処理時間の確認– 全員分の処理が完了したあとに次のステータス– 外部インターフェイスが変わる調整
• まとめて実行できるなら Step Functions• 単発リクエストがいっぱい来るなら遅延 SQS
かな？
#jawsdays #jd2017_a
まとめ• 状況・時代によって最適なアーキテクチャは変わる• 運用・管理のしやすさも考慮しないと⇒ やっぱり難しい。。次回の JAWS-UG アーキテクチャ専門支部 3/21( 火 )ハイブリッドクラウド分科会 CDP 取りまとめ会 #4
アーキテクチャ専門支部で一緒に検討しましょう！
