Copyright © 2015. All rights reserved.
2015年11月03日
JAWS Festa 九州 2015
ハンズラボ株式会社 井上泰治
AWS活用の今までとこれから。
ー 東急ハンズの事例 ー
1
もくじ
1. 自己紹介
2. AWS活用 今までとこれから
3. 東急ハンズの事例
2
自己紹介
名前: 井上 泰治
所属: ハンズラボ株式会社
担当: ECシステム、AWSまわり
趣味: 旅行、音楽、日本酒
好きなAWSサービス: ElasticBeanstalk
3
2. AWS活用 今までとこれから。
4
AWSの歴史 (抜粋)
2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
S3
EC2
SQS
Tokyo Region
VPC
RDS
EMR DynamoDB
Lambda
ECS
Cognito
CodeDeploy
API Gateway
Mobile Hub
IoT
CloudFront
CloudFormation
SNS
IAM
Route53
Beanstalk
Redshift
OpsWorks
Kinesis
デプロイ系サービス
コンピューティング
マネージド OSSのマネージド化
切り売り
ストリーム/ビッグデータ
モバイル/iOT
5
AWSの提供するもの
AWSサー
ビス
汎用計算
リソース
リソースの
ソフトウェ
ア提供
OSSソフ
トウェア
マネージ
ドソフト
ウェアストレージ
ネットワー
ク
(半マネージド)
AWSサービスの増加、
利用者側の意識変化により、
使われ方も徐々に変化
OSSソフ
トウェア
6
AWS導入初期
汎用計算
リソース
マネージ
ドソフト
ウェアストレージ
EC2
Apache / Nginx
PHP / Ruby
オンプレのシステムを
とりあえずAWSにのせた状態
ネットワー
ク
AWSサー
ビス
(半マネージド)
リソースの
ソフトウェ
ア提供
MySQL、 Redis
OSSソフ
トウェア
7
マネージド・サービスの活用
汎用計算
リソース
マネージ
ドソフト
ウェアストレージ
ネットワー
ク
AWSサー
ビス
(半マネージド)
リソースの
ソフトウェ
ア提供
EC2
EC2に乗せていたソフトウェアを
マネージドシステムへの移行
Elasticache
RDS
ElasticSearch
SQS
DynamoDB
Redshift
S3 EMR
8
EC2管理コストの削減
この状態の場合、EC2の保守運用が残る
汎用計算
リソース
OSSソフ
トウェア
マネージ
ドソフト
ウェア
ストレージ
利用
利用
利用
EC2
EC2が各サービスを利用
する状態
EC2の運用負荷を下げるには…
9
EC2管理コストの削減
マネージドシステムからEC2を使う
汎用計算
リソース
OSSソフ
トウェア
マネージ
ドソフト
ウェア
ストレージ
利用
利用
利用
EC2
マネージ
ドソフト
ウェア
Beanstalk
EC2を直接使わないことで
運用負荷の低減
ECS
ペットから
家畜へ
10
EC2管理コストの削減
そもそもEC2を使わない ① lambda の活用
汎用計算
リソース
サーバー
→ EC2
ソフトウェア
→ コンテナ
関数
→ lambda
アプリケーション
ミドルウェア
OS
アプリケーション
最低限の実行環境
アプリケーション
計算リソースが
より細かい単位で
利用可能に
コレを使う
11
Cognito
DynamoDB
S3
SQS
JavaScript SDK
Mobile SDK
そもそもEC2を使わない ① lambda の活用
API Gateway Lambda
アプリケーションロ
ジックはここに持つ
EC2管理コストの削減
12
そもそもEC2を使わない ② 2 tier アーキテクチャ
マネージ
ドソフト
ウェア Cognito
DynamoDB
S3
SQS
クライアントが
直接AWSリソースを操作
JavaScript SDK
Mobile SDK
アプリケーションロ
ジックはここに持つ
Lambda
認証
EC2管理コストの削減
13
これらのAWSクラウドネイティブの話は西谷さんのスライドがわかりやすいです。
『Serverless Architecture on AWS
クラウドネイティブ化する未来』
http://www.slideshare.net/keisuke69/serverless-architecture-on-aws
14
3. 東急ハンズでのAWS活用
今までとこれから
15
1. レガシーアプリのクラウド最適化
ネットストアでの事例
3. クラウドネイティブアーキテクチャを活用した
ポイントシステムの開発
2. AWS新サービスを使ってみた。
おみやげ配布アプリケーションの構築
16
AWS上にシステムを構築したものの
全然スケールしないシステム
17
ECサイトの宿命: セール時のスパイクアクセス
0.00
50.00
100.00
150.00
200.00
250.00
300.00
350.00
400.00
450.00
500.00
2014-08-2723:40
2014-08-2723:44
2014-08-2723:48
2014-08-2723:52
2014-08-2723:56
2014-08-2800:00
2014-08-2800:04
2014-08-2800:08
2014-08-2800:12
2014-08-2800:16
2014-08-2800:20
2014-08-2800:24
2014-08-2800:28
2014-08-2800:32
2014-08-2800:36
2014-08-2800:40
2014-08-2800:44
2014-08-2800:48
2014-08-2800:52
2014-08-2800:56
2014-08-2801:00
2014-08-2801:04
2014-08-2801:08
2014-08-2801:12
2014-08-2801:16
2014-08-2801:20
2014-08-2801:24
2014-08-2801:28
2014-08-2801:32
2014-08-2801:36
2014-08-2801:40
2014-08-2801:44
2014-08-2801:48
2014-08-2801:52
2014-08-2801:56
セール開始
昇竜拳を思わせる
無慈悲なアクセス増
18
以前のネットストアの状態
WEB Servers API Servers
ELB ELB
データをファイルで持っていたた
め、サーバを増やすごとにファイ
ル同期コストが増大
ユーザ
スケールアウトは手動 プロセス数増大
APIレスポンス
待ち行列が増加
19
改善後のネットストアの状態
WEB Servers API Servers
ELB
Data Layer
DynamoDB
S3
データ層は単一障害点にならな
いアーキテクチャの中から選定
Elastic Beanstalk
Beanstalk による Auto Scale
Blue Green Deployment
ユーザ
Elastic Beanstalk
ELB
アクセス増加時は、ス
ループットを上げるだけ
20
開発/デプロイフロー
Env: BLUE
Env: GREEN
Env: STG
開発者
WEB
WEB
① 開発
② ステージングにデプロイ
$ eb depoy
④ GREENに同Versionをデプロイ
③ 動作確認
⑤ 環境のSWAP
ステージング環境
本番環境
$ aws elasticbeanstalk swap-environment-cnames 
--region ap-northeast-1 
--source-environment-name green 
--destination-environment-name blue
マネージメントコンソールにて
ローカル環境
(Atlassian Stash)
(⑥何か問題があった
ら SWAPして戻す)
21
環境構築自動化例 ( ebextensions による設定)
22
この状態になるまでに、
1年半くらいかかりました。
この間の非常に泥臭い作業について
お話します。
23
1. ボトルネックの特定
WEB Servers API Servers
ELB ELB
ユーザ
1番のボトルネックがスケールでき
ないAPIサーバーと特定、
ここの改善から始めることに決定
100本以上のAPI
10万行以上のソースコード
数ヶ月後には、昨年負荷に耐えられなかっ
たセールを控えている状況
24
API
コール数
ここを直すだけで、全体の半分以上の
リクエスト数をカバー。
コール数の多いセッション系APIなど
改修の対象として選定
コール頻度の低いものは後回し
2. 改修対象の選定
時間的制約により、セール前に全てを直すこ
とは不可能なので、1日あたりのAPIコール
数を調査し、最も多くコールされているAPIか
ら順番に改修していくことに。
25
3. 改修方法の決定
既存のAPIサーバーは、数年前に立てられたもので、
諸々のミドルウェアが古い状態
依存関係も不明のため、アップデートも困難
既存サーバー内で改修するのではなく、
新環境を用意して、新環境で新しいAPIを構築することに。
26
3. 改修方法の決定
WEB
APP
サーバー
旧APIサーバー
新APIサーバー
機能A
機能A
① 改修
<案1> APPサーバーでの新旧切り替え
② 切り替え
新APIでの実装が終わったら、
APPサーバーでコール先を変更
する
1. APPサーバー側での改修が必要
2. リリース及び切り戻し時、APPサーバーチームで
切り替え作業を行う必要がある
☓却下
27
3. 改修方法の決定
WEB
APP
サーバー
旧APIサーバー新APIサーバー
<案2> ReverseProxyでの切り替え
機能AProxy
機能A
① 改修
② 切り替え
Proxyの設定変更でリリース
APIサーバー開発チームだけで自由にリリース/切り戻し
作業が行える。
APPサーバーチームは改修の必要なし。
◎ 採用
28
WEB Servers 新API Servers
兼Proxyサーバ
ELB
Data Layer
DynamoDBS3
• 1レイヤ追加
• Elastic Beanstalkの導入
ユーザ
旧API Servers
既存環境に1レイヤ追加された状態に
新旧APIが混在のため、
データ同期が必要
29
4. DynamoDBとファイルのデータ同期
Worker
(ファイル監視)
CGI
(Batch)
Worker
(DynamoDB更新)
ファイル
更新
call
ファイルを監視して
SQSに登録
キューを監視してDynamoDBを更新
SQS
DynamoDB
(CGI、バッチ処理のファイル更新をDynamoDBに反映)
json
30
4. DynamoDBとファイルのデータ同期
CGI PHP
Node.js
外部コマンド
call
DynamoDB
HTTP
(CGIからDynamoDB参照)
JSON
bash から aws cli で
DynamoDBたたくのは、かな
りしんどくてこうなりました。
31
5. あとはひたすら機能の移植
WEB
APP
サーバー
旧APIサーバー新APIサーバー
機能AProxy
機能A
① 改修
② 切り替え
旧APIサーバーの機能がなくなるまで、
① 改修 と ②切り替えを繰り返す。
(まだ道半ば)
32
<やっとスケールできるシステムになりました>
WEB Servers API Servers
ELB
Data Layer
DynamoDB
S3
Elastic Beanstalk
ユーザ
Elastic Beanstalk
ELB
環境構築
自動化
Auto Scale
33
クラウドを導入したら自動的にスケールする
システムになったり、運用負荷が下がるわけではない。
疎結合はとても重要。
クラウドのやり方に自分たちをフィットさせていく
必要がある。
34
今 システムがイケてなくても
悲観しないでください。
問題に向き合い、試行錯誤して苦労した分、確実に
個々人及び会社の成長につながります。
時間はかかるかもしれませんが、
お互いがんばりましょう。
35
1. レガシーアプリのクラウド最適化
ネットストアでの事例
3. クラウドネイティブアーキテクチャを活用した
ポイントシステムの開発
2. AWS新サービスを使ってみた。
おみやげ配布アプリケーションの構築
36
先日ラスベガスで行われた AWS のイベント
re:Invent に参加させていただきました。 今年もたくさん新サービスや
アップデートの発表がありまし
た!
新サービスは無理やりでも使おう
EC2をなるべく使わない縛りプレイ
なるべく少ない労力で
AWS re:Inventの報告として、ただ新サービス
を紹介してもつまらない
(某blogの会社の方が早いし、詳しいし…)
新サービスを実際に使って何かアプリケーショ
ンを作ってみたら良いのでは
おみやげの配布を新サービスつかってやって
みては?
37
という話に帰りの空港で盛り上がり、設計を開始
飛行機の中でもあれこれと議論を行いました。
使うサービスと使わないサービスの選別や
サービス間の連携方法、
テーブル設計はどうしよう 、などなど。
きっかけ コンセプト
38
ざっくりと要件
1. お土産の一覧を見ることができる。
2. 欲しいお土産に応募できる
1. 応募状況が確認できる
2. お土産の抽選が行える
ユーザー側機能
管理者機能
39
設計したらこうなった
40
Lambda
Kinesis
Firehose
Cloud Front
API Gateway
Cognito
DynamoDB
user
client
API
HTML
JS Image
認証
権限
S3
RedShift
Lambda
Facebook
WAF
Lambda
Administrator
- List Items
- Create User
- Entry
- List Entries
- Report (cron)
SNS
Administrator
- お土産リストの確認
- 欲しいお土産のエントリ
- おみやげ抽選
- レポート
3. おみやげ配布アプリを新サービスを使って作ってみた
アーキテクチャ
41
Lambda
Kinesis
Firehose
Cloud Front
API Gateway
Cognito
DynamoDB
user
client
API
HTML
JS Image
認証
権限
S3
RedShift
Lambda
Facebook
WAF
Lambda
Administrator
- List Items
- Create User
- Entry
- List Entries
- Report (cron)
SNS
Administrator
- お土産リストの確認
- 欲しいお土産のエントリ
- おみやげ抽選
- レポート
3. おみやげ配布アプリを新サービスを使って作ってみた
アプリケーションはJavaScriptによる
シングル−ページアプリケーション
気づいたらiOSアプリも出来てた
配信は CloudFront (S3オリジン)
無駄にWAF
42
Lambda
Kinesis
Firehose
Cloud Front
API Gateway
Cognito
DynamoDB
user
client
API
HTML
JS Image
認証
権限
S3
RedShift
Lambda
Facebook
WAF
Lambda
Administrator
- List Items
- Create User
- Entry
- List Entries
- Report (cron)
SNS
Administrator
- お土産リストの確認
- 欲しいお土産のエントリ
- おみやげ抽選
- レポート
3. おみやげ配布アプリを新サービスを使って作ってみた
認証は Facebook
権限付与は Cognito
43
Lambda
Kinesis
Firehose
Cloud Front
API Gateway
Cognito
DynamoDB
user
client
API
HTML
JS Image
認証
権限
S3
RedShift
Lambda
Facebook
WAF
Lambda
Administrator
- List Items
- Create User
- Entry
- List Entries
- Report (cron)
SNS
Administrator
- お土産リストの確認
- 欲しいお土産のエントリ
- おみやげ抽選
- レポート
3. おみやげ配布アプリを新サービスを使って作ってみた
データは、API Gateway + Lambda
を経由してDynamoDBへ
LambdaはPythonを使用
44
Lambda
Kinesis
Firehose
Cloud Front
API Gateway
Cognito
DynamoDB
user
client
API
HTML
JS Image
認証
権限
S3
RedShift
Lambda
Facebook
WAF
Lambda
Administrator
- List Items
- Create User
- Entry
- List Entries
- Report (cron)
SNS
Administrator
- お土産リストの確認
- 欲しいお土産のエントリ
- おみやげ抽選
- レポート
3. おみやげ配布アプリを新サービスを使って作ってみた
DynamoDBに入った応募データは
LambdaからFirehoseでS3経由
Redshiftへ
ただ、Lambdaコンテナ上の
AWS SDKが古くて
Firehoseが呼び出せず実現
せず。
45
Lambda
Kinesis
Firehose
Cloud Front
API Gateway
Cognito
DynamoDB
user
client
API
HTML
JS Image
認証
権限
S3
RedShift
Lambda
Facebook
WAF
Lambda
Administrator
- List Items
- Create User
- Entry
- List Entries
- Report (cron)
SNS
Administrator
- お土産リストの確認
- 欲しいお土産のエントリ
- おみやげ抽選
- レポート
3. おみやげ配布アプリを新サービスを使って作ってみた
Lambdaの定期実行(CRON)を使っ
て 応募状況をSNSでレポート
46
テクノロジーの
無駄遣い
47
報告会 兼 おみやげ抽選会
48
報告会 兼 おみやげ抽選会
49
Lambdaコード抜粋 (応募状況を返すAPI)
Pythonで書いたらすごく
シンプルに書けた!
50
やってみて良かったこと
新サービスをむりやり使う方針によって
どんなサービスがあったか復習できた。
想定ユースケースの確認ができた
新サービスを使ってみて
サービスの概要を把握できた
一回手を動かしてみることで、苦手意識が低下した
Lambda力が増した
API Gatewayが使えるようになった
Node.jsの辛さを再認識した
Pythonに目覚めた
サーバーレスアーキテクチャも行けそうな気がしてきた
51
サーバーレスアーキテクチャについて
API Gatewayの登場によりより現実感が増した。
2 Tier アーキテクチャは用途が限定的なイメージ
デプロイ系はまだこなれてない
開発方法、運用方法についてノウハウの蓄積が必要
デプロイ手法の確立 (JAWS frameworkなど)
ブラウザでポチポチするのは辛い。
ログまわり (CloudwatchLogs辛い)
認証まわりがまだふわっとしてる(自分の中で)
うまくいけばコストダウンになりそう
52
新しい技術を学ぶのには
“しばり”があると面白い
新サービス
しばり
EC2レス
しばり
Lambdaし
ばり
53
1. レガシーアプリのクラウド最適化
ネットストアでの事例
3. クラウドネイティブアーキテクチャを活用した
ポイントシステムの開発
2. AWS新サービスを使ってみた。
おみやげ配布アプリケーションの構築
54
• EC2レス
• マネージドシステムのフル活用
• DynamoDB、Cognito、SQS、S3、STS…
• Lambda + API Gatewayの採用
東急ハンズのポイントシステムを
AWS フルマネージドで構築する作業を進めています。
特徴
新ポイントシステム基盤 AWS全体構成
5555
56
まとめ
クラウドはものすごい速さで進化している。
いままでのやり方が、少しすれば古いやり方に
次々と新しい概念や仕組みが現れるので、勉強
して自分たちもシステムも成長させよう。
57
まとめ
大変なことも多いけど、自分たちの頭で考えてシス
テムを作っていくのは楽しい。
AWSの勉強会は各地で行われています。困ったら
相談しよう。(相談に乗ってください)
一緒にクラウドのよりよい活用方法を考えて行きま
しょう!
58
ご静聴
ありがとうございました。
Do It Yourself

AWS活用のいままでとこれから -東急ハンズの事例-