1.
#jawsdays #jd2017_a

2.
#jawsdays #jd2017_a
自己紹介
氏名：金平晃尚
職業：フリーランス（2016年3月末～）
得意：インフラ、データベース、プログラミング
好きな言語： Java, Python
好きなAWSサービス：Lambda, EMR
JAWS：CLI専門支部、アーキテクチャ専門支部、ビッグデータ支部
AWS：2016/6から本格使用開始、2016/12 Re:Invent自費参加
資格：
Since 2017/03/09(木)

3.
#jawsdays #jd2017_a
今日のお話の全体構成図
Office
Direct Connect
VPN
connection
Cloud Front Route 53
RDS DB
instance
RDS DB
instancestandby(multi-
AZ)
AWS Directory
Service
Amazon API
Gateway
Amazon
Cognito
AWS
Lambda
Amazon
DynamoDB
Amazon
S3
AMI
Auto Scaling
EC2
Amazon
Provided
DNS
EC2
Staging
server
Prod
server
Prod
server
Bastion
server
corporate data center
EC2
Elastic Load Balancing
EC2
DNS Server

4.
#jawsdays #jd2017_a
マイクロサービスアーキテクチャ(1/2)
EC2, RDSで作る3層構成は
オンプレから比較的簡単に移行できるパターン
でも維持費はけっこうかかるので対策したい
１．リザーブド/スポットインスタンスを使ったり
処理のピークに合わせてスケールさせる
２．使った分だけ支払いのAWSマネージドサービスを活用する
EC2：1時間単位の料金設定
Lambda：100ミリ秒単位の料金設定
マイクロサービス
アーキテクチャと
相性がいい

5.
#jawsdays #jd2017_a
マイクロサービスアーキテクチャ(2/2)
一枚岩（モノリシック）な大きなシステムを作りこむのでなく、
小さなサービスを組み合わせてシステムを作る
特徴 効果
サービス単位の組織 意思疎通しやすい規模
サービス間は疎結合で
外部インターフェース間でのみ通信
内部実装はチームごとに自由に作れる
バージョンアップも単独実施可能
サーバに状態を持たない
ステートレス、イミュータブル
環境の複製、再作成が簡単
必要なサービスだけスケールできる
各サービスの実装は比較的簡単 単体テストは易しい
総合テストは難しい
処理の自動化 コード修正後勝手にテストなど
早いリリースサイクルを実現

6.
#jawsdays #jd2017_a
マネージドサービスの活用(1/2)
マネージドサービスへ
の置き換え
特徴と対応
EC2 ⇒ Lambda 最大メモリ1.5GB。最大処理時間5分。3回リトライ。
まれに発火しないときがある。
何度実行しても同じ結果を返すように実装すること。
EBS ⇒ S3 大容量のストレージ。結果整合性。安い。
データをローカルに持ってくるところからはじめる。
RDS ⇒ DynamoDB スループット保証のKVS。札束でたたくと強くなる。
トランザクションは自前での実装が必要。
監視 ＝ CloudWatch 総合テストが難しいのは流れを見失いがちなため。
トランザクションIDを取りまわすなど工夫を。
新サービスX-Ray が解決してくれるかもしれない。
AWS X-Ray

7.
#jawsdays #jd2017_a
マネージドサービスの活用(2/2)
• 最適に活用すれば維持/管理コストが下げられる
– 目的を達成する方法が複数ある
– サービスが多すぎて最適な設計がわからない
⇒最適解は用途と規模と時代で変わるので、
持っているスキル・開発期間・リスク・リターンを考慮して適宜見直していく。
効果が高い部分から順番に対応していく。
既存システムの置き換えをやる前に
簡単な新規サービスで使ってみてノウハウを貯めるなど。
疎結合な設計なら部分的に見直せる。
汎用性の高いものはCDPにしていきたい。

8.
#jawsdays #jd2017_a
解決したい課題１
• サーバを使わずに動的なWebサービスを作りたい
• 独自ドメインを使いたい
• HTTP/2を使いたい
• 800GET/秒を超えるアクセスをさばきたい
• ユーザを管理したい
• コストを削減したい

9.
#jawsdays #jd2017_a
Amazon
Route 53
AWS
Lambda
Amazon
DynamoDB
Amazon
CloudFront
Amazon API
Gateway
users
Amazon
Cognito
Amazon
S3
Cognito UserPoolsでユーザを管理
認証した人だけAPI Gatewayにアクセス可能
マルチデバイス/アカウント対応な実装も可能
静的なコンテンツはS3へ配置
動的な処理はjavascriptのライブラリで通信
APIGateway＋cognito認証パターン(1/2)
とりあえず認証だけCognito使って
コンテンツはEC2というのも可能
サーバレスで会員専用サイトを作るパターン
①
②
③
④
ドメインはRoute53で管
理

10.
#jawsdays #jd2017_a
APIGateway＋cognito認証パターン(2/2)
利点
• ユーザ認証した人だけがAPIを実行できる
• Facebookやtwitterアカウントでのログオンも作れる
（ Cognito Federated Identities ）
• 各言語向けSDKがあるので
バックエンドはアプリと共通化できる
注意点
• CognitoのUserPoolsを直接使うときと
Federated Identitesを使うときで
認証の書き方が違うのでハマりやすい

11.
#jawsdays #jd2017_a
解決したい課題２
• URLへの初回アクセス時にコンテンツを生成し、
2回目以降は同じ内容のコンテンツを返したい
例）
• 検索キーワードを元にコンテンツを生成するなど事前処理が難しい場合
• 対象データ量は膨大だけどアクセスされるURLが限定されているため
ディスク容量を節約したい場合
• コンテンツ生成処理にAPIスロットリング制限があって
生成の回数を減らしたい場合

12.
#jawsdays #jd2017_a
Amazon
S3
Amazon
CloudFront
AWS
Lambda
users
Amazon
Route 53
Amazon API
Gateway
すべてのファイルをキャッシュしないカスタム設定
ファイルがないとき(404)は生成処理へのリ
ダイレクト(307)を返すリダイレクトルール
必要なら仮のファイルをS3に設置して
時間稼ぎ
コンテンツ遅延生成パターン(1/2)
URLへの初回アクセス時にコンテンツを生成し、
2回目以降は同じ内容のコンテンツを返したいときのパターン
① ②
③
本物のファイルはキャッシュ設定をつけ
た上で設置

13.
#jawsdays #jd2017_a
コンテンツ遅延生成パターン(2/2)
利点
• 大きいキャッシュを持つより安い
注意点
• CloudFrontはデフォルトでは307 Temporary Redirectでさえも
キャッシュするのでカスタム設定が必要
• キャッシュが必要なファイルには明示的にS3タグを指定
• S3の低冗長化ストレージ(RRS)を使えばコスト削減？
2016年12月以降、東京リージョンはRRSの方が高くなった。
というかシンガポール・ムンバイ・サンパウロ以外全部高い！
Qiita記事: http://qiita.com/kyane/items/7e093ed5b4478181b491

14.
#jawsdays #jd2017_a
解決したい課題３
• 時間のかかる重たいAPIの処理結果を受けて別の処理を走らせたい
≒処理が終わるのを数分間隔でポーリングしたい
例）
実店舗の在庫数とオンラインショップの在庫数を
合わせるために在庫ファイルをアップロードする

15.
#jawsdays #jd2017_a
SQS
AWS
Lambda
AWS
Lambda
時間のかかる処理が終わるまでポーリングするパターン
何かのWebサービス
AWS
Lambda
①重たいリクエスト ③ステータス確認のポーリング
NG：遅延QUEUEに再度投入
OK：結果を取得して次の処理へ
API処理結果ポーリングパターン(1/4)
NG
OK
②遅延QUEUEで数分後
にポーリング
遅延はSQSで実現できそうだけど
SQSはプル型のサービスなのでLambdaは直接連携できない・・・・
？

16.
#jawsdays #jd2017_a
SQS
AWS
Lambda
AWS
Lambda
CloudWatchEvent（linuxでいうところのcron）を使う
何かのWebサービス
AWS
Lambda
①重たいリクエスト ③ステータス確認のポーリング
NG：遅延QUEUEに再度投入
OK：結果を取得して次の処理へ
API処理結果ポーリングパターン(2/4)
NG
OK
②遅延QUEUEで数分後
にポーリング
CloudWatch
Event
(time-based)
⇒SQSはGetしてもQueueの内容を全部取れない。
CloudWatchイベントは最小1分間隔。思ったよりさばけない。

17.
#jawsdays #jd2017_a
AWS Elastic
BeanstalkSQS
AWS
Lambda
AWS
Lambda
ElasticBeanstalkのWorkerを使う
何かのWebサービス
AWS
Lambda
①重たいリクエスト ③ステータス確認のポーリング
NG：遅延QUEUEに再度投入
OK：結果を取得して次の処理へ
API処理結果ポーリングパターン(3/4)
NG
OK
②遅延QUEUEで数分後
にポーリング
BeanstalkのWorkerはSQSのメッセージを処理するEC2上のWebサーバ
Lambdaを同期実行するだけの処理を書く

18.
#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分なのでそれ以上は小細工が必要

19.
#jawsdays #jd2017_a
AWS Step Functions
これStep Functionsでよくね？

20.
#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 回/秒

21.
#jawsdays #jd2017_a
Step Functionsとは(2/2)
Type 説明
Task Lambda: プッシュ型実行
Activity: プル型実行
Parallel すべての処理が完了したら次の状態へ。
並列度は動的には変更できない
Choice 変数の値により次の状態を切り替える分岐
Wait 指定した時間 or 日時まで待つ（最大1年）
Pass 何もしない
Succeed 正常終了
Fail 異常終了
ステートマシン - 状態遷移図に従った動作(Amazon State Language(JSON))で定
義)

22.
#jawsdays #jd2017_a
API処理結果
ポーリングパターン(Step Functions版)
1回リトライすると遷移回数は9回。
1,000ユーザのタスクを1時間に1回実行するケース
• API制限そのままだと全部実行するには1,800秒かかる
• 料金は
$0.000025 × 9回 × 24時間 × 30日 × 1,000人 = $162
⇒1,000人ずつ処理する方式にすると$0.162になるけど
– Lambdaのメモリ、処理時間の確認
– 全員分の処理が完了したあとに次のステータス
– 外部インターフェイスが変わる調整
• まとめて実行できるならStep Functions
• 単発リクエストがいっぱい来るなら遅延SQS かな？

23.
#jawsdays #jd2017_a
まとめ
• 状況・時代によって最適なアーキテクチャは変わる
• 運用・管理のしやすさも考慮しないと
⇒やっぱり難しい。。
次回の JAWS-UG アーキテクチャ専門支部
3/21(火)ハイブリッドクラウド分科会 CDP取りまとめ会 #4
アーキテクチャ専門支部で一緒に検討しましょう！