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

Copyright © 2015. All rights reserved.

2015 年 11 月 03 日JAWS Festa 九州 2015

ハンズラボ株式会社　井上泰治

AWS 活用の今までとこれから。　ー　東急ハンズの事例　ー

2

もくじ

1. 自己紹介

2. AWS 活用今までとこれから

3. 東急ハンズの事例

3

自己紹介

名前：　井上　泰治

所属：　ハンズラボ株式会社

担当：　 EC システム、 AWS まわり

趣味：　旅行、音楽、日本酒

好きな AWS サービス： ElasticBeanstalk

4

2. AWS 活用　今までとこれから。

5

AWS の歴史（抜粋）

2006 2007 2008 2009 2010 2011 2012 2013 2014 2015

S3EC2SQS

Tokyo Region

VPCRDSEMR DynamoDB

LambdaECSCognitoCodeDeploy

API GatewayMobile HubIoT

CloudFront

CloudFormationSNSIAMRoute53Beanstalk

RedshiftOpsWorksKinesis

デプロイ系サービス

コンピューティングマネージド OSS のマネージド

化

切り売り

ストリーム / ビッグデータ

モバイル /iOT

6

AWS の提供するもの

AWSサービス

汎用計算リソース

リソースのソフトウェア提供

OSS ソフトウェア

マネージドソフトウェアストレー

ジ

ネットワーク

( 半マネージド )

AWS サービスの増加、利用者側の意識変化により、使われ方も徐々に変化

7


AWS 導入初期



ジ

EC2

Apache / Nginx

PHP / Ruby

オンプレのシステムをとりあえず AWS にのせた状態

ネットワーク

AWSサービス

( 半マネージド )リソースのソフトウェア提供

MySQL 、 Redis

8


マネージド・サービスの活用



ジ

ネットワーク

AWSサービス

( 半マネージド )リソースのソフトウェア提供

EC2

EC2 に乗せていたソフトウェアをマネージドシステムへの移行

Elasticache

RDS

ElasticSearch

SQS

DynamoDB

Redshift

S3 EMR

9

EC2 管理コストの削減

この状態の場合、 EC2 の保守運用が残る



マネージドソフトウェア

ストレージ

利用

利用

利用

EC2

EC2 が各サービスを利用する状態

EC2 の運用負荷を下げるには…

10


マネージドシステムから EC2 を使う




ストレージ

利用

利用

利用

EC2


Beanstalk

EC2 を直接使わないことで運用負荷の低減

ECS

ペットから家畜へ

11


そもそも EC2 を使わない ① lambda の活用


サーバー　→ EC2

ソフトウェア　→ コンテナ

関数　→ lambda

アプリケーションミドルウェアOS

アプリケーション最低限の実行環境

アプリケーション

計算リソースがより細かい単位で利用可能に

コレを使う

12

Cognito

DynamoDB

S3

SQS

JavaScript SDK

Mobile SDK

そもそも EC2 を使わない ① lambda の活用

API Gateway Lambda

アプリケーションロジックはここに持つ


13

そもそも EC2 を使わない ② 2 tier アーキテクチャ


Cognito

DynamoDB

S3

SQS

クライアントが直接 AWS リソースを操作

JavaScript SDK

Mobile SDKアプリケーションロジックはここに持つ

Lambda

認証


14

これらの AWS クラウドネイティブの話は西谷さんのスライドがわかりやすいです。

『 Serverless Architecture on AWS 　　　　　　　　クラウドネイティブ化する未来』

http://www.slideshare.net/keisuke69/serverless-architecture-on-aws

15

3. 東急ハンズでの AWS 活用

　　　　　　　今までとこれから

16

1. レガシーアプリのクラウド最適化　　ネットストアでの事例

3. クラウドネイティブアーキテクチャを活用した　ポイントシステムの開発

2. AWS 新サービスを使ってみた。　　　おみやげ配布アプリケーションの構築

17

AWS 上にシステムを構築したものの

全然スケールしないシステム

18

EC サイトの宿命：　セール時のスパイクアクセス

2014-08-27 23:402014-08-28 00:022014-08-28 00:242014-08-28 00:462014-08-28 01:082014-08-28 01:302014-08-28 01:520.00

50.00

100.00

150.00

200.00

250.00

300.00

350.00

400.00

450.00

500.00 セール開始昇竜拳を思わせる

無慈悲なアクセス増

19

以前のネットストアの状態

WEB Servers API Servers

ELB ELB

データをファイルで持っていたため、サーバを増やすごとにファイル同期コストが増大

ユーザ

スケールアウトは手動プロセス数増大

API レスポンス待ち行列が増加

20

改善後のネットストアの状態


ELB

Data Layer

DynamoDB

S3

データ層は単一障害点にならないアーキテクチャの中から選定

Elastic Beanstalk

Beanstalk による Auto ScaleBlue Green Deployment

ユーザ

Elastic Beanstalk

ELB

アクセス増加時は、スループットを上げるだけ

21

開発 / デプロイフロー

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 して戻

す )

22

環境構築自動化例 ( ebextensions による設定）

23

この状態になるまでに、1 年半くらいかかりました。

この間の非常に泥臭い作業についてお話します。

24

1. ボトルネックの特定


ELB ELB

ユーザ

1番のボトルネックがスケールできない API サーバーと特定、ここの改善から始めることに決定

100 本以上の API10万行以上のソースコード

数ヶ月後には、昨年負荷に耐えられなかったセールを控えている状況

25

API

コール数

ここを直すだけで、全体の半分以上のリクエスト数をカバー。

コール数の多いセッション系 API など改修の対象として選定

コール頻度の低いものは後回し

2. 改修対象の選定時間的制約により、セール前に全てを直すことは不可能なので、 1 日あたりのAPI コール数を調査し、最も多くコールされている API から順番に改修していくことに。

26

3. 改修方法の決定

既存の API サーバーは、数年前に立てられたもので、諸々のミドルウェアが古い状態

依存関係も不明のため、アップデートも困難

既存サーバー内で改修するのではなく、新環境を用意して、新環境で新しい API を構築することに。

27


WEBAPPサーバー

旧 API サーバー

新 API サーバー

機能 A

機能 A

① 改修

＜案１＞ APP サーバーでの新旧切り替え

② 切り替え

新 API での実装が終わったら、APP サーバーでコール先を変更する

1. APP サーバー側での改修が必要2. リリース及び切り戻し時、 APP サーバー

チームで　　切り替え作業を行う必要がある

☓却下

28


WEBAPPサーバー


新 API サーバー

＜案 2＞ ReverseProxy での切り替え

機能 AProxy

機能 A① 改修

② 切り替え

Proxy の設定変更でリリース

API サーバー開発チームだけで自由にリリース／切り戻し作業が行える。APP サーバーチームは改修の必要なし。

◎ 採用

29

WEB Servers 新 API Servers兼 Proxy サーバ

ELB

Data Layer

DynamoDBS3

• １レイヤ追加• Elastic Beanstalk の導入

ユーザ

旧 API Servers

既存環境に 1 レイヤ追加された状態に

新旧 API が混在のため、データ同期が必要

30

4. DynamoDB とファイルのデータ同期

Worker( ファイル監視 )

CGI(Batch)

Worker(DynamoDB更新 )

ファイル

更新call

ファイルを監視してSQS に登録

キューを監視して DynamoDB を更新

SQSDynamoDB

(CGI 、バッチ処理のファイル更新を DynamoDB に反映 )

json

31

4. DynamoDB とファイルのデータ同期

CGI PHPNode.js

外部コマンドcall

DynamoDB

HTTP

(CGI から DynamoDB参照 )

JSONbash から aws cli で DynamoDB たたくのは、かなりしんどくてこうなりました。

32

5. あとはひたすら機能の移植

WEBAPPサーバー


新 API サーバー機能 AProxy

機能 A① 改修

② 切り替え

旧 API サーバーの機能がなくなるまで、① 改修　と ②切り替えを繰り返す。（まだ道半ば）

33

＜やっとスケールできるシステムになりました＞


ELB

Data Layer

DynamoDB

S3

Elastic Beanstalk

ユーザ

Elastic Beanstalk

ELB

環境構築自動化

Auto Scale

34

クラウドを導入したら自動的にスケールするシステムになったり、運用負荷が下がるわけではない。

疎結合はとても重要。

クラウドのやり方に自分たちをフィットさせていく必要がある。

35

今　システムがイケてなくても悲観しないでください。

問題に向き合い、試行錯誤して苦労した分、確実に個々人及び会社の成長につながります。

時間はかかるかもしれませんが、お互いがんばりましょう。

36




37

先日ラスベガスで行われた AWS のイベント re:Invent に参加させていただきました。今年もたくさん新サービス

やアップデートの発表がありました！

38

新サービスは無理やりでも使おうEC2 をなるべく使わない縛りプレイなるべく少ない労力で

AWS re:Invent の報告として、ただ新サービスを紹介してもつまらない(某 blog の会社の方が早いし、詳しいし…）新サービスを実際に使って何かアプリケーションを作ってみたら良いのではおみやげの配布を新サービスつかってやってみては？

という話に帰りの空港で盛り上がり、設計を開始飛行機の中でもあれこれと議論を行いました。

使うサービスと使わないサービスの選別やサービス間の連携方法、テーブル設計はどうしよう、などなど。

きっかけコンセプト

39

ざっくりと要件

1. お土産の一覧を見ることができる。2.欲しいお土産に応募できる

1.応募状況が確認できる2. お土産の抽選が行える

ユーザー側機能

管理者機能

40

設計したらこうなった

41

Lambda

Kinesis Firehose

Cloud Front

API Gateway

Cognito

DynamoDB

userclient

API

HTMLJS Image

認証

権限

S3

RedShift

Lambda

Facebook

WAF

Lambda

Administrator

- List Items- Create User - Entry- List Entries

- Report (cron)

SNS

Administrator

- お土産リストの確認- 欲しいお土産のエントリ

- おみやげ抽選

- レポート

3. おみやげ配布アプリを新サービスを使って作ってみた

アーキテクチャ

42

Lambda

Kinesis Firehose

Cloud Front

API Gateway

Cognito

DynamoDB

userclient

API

HTMLJS Image

認証

権限

S3

RedShift

Lambda

Facebook

WAF

Lambda

Administrator


- Report (cron)

SNS

Administrator



- レポート


アプリケーションは JavaScript によるシングルページアプリケーショ−ン気づいたら iOS アプリも出来てた配信は CloudFront （ S3 オリジン）無駄に WAF

43

Lambda

Kinesis Firehose

Cloud Front

API Gateway

Cognito

DynamoDB

userclient

API

HTMLJS Image

認証

権限

S3

RedShift

Lambda

Facebook

WAF

Lambda

Administrator


- Report (cron)

SNS

Administrator



- レポート


認証は Facebook権限付与は Cognito

44

Lambda

Kinesis Firehose

Cloud Front

API Gateway

Cognito

DynamoDB

userclient

API

HTMLJS Image

認証

権限

S3

RedShift

Lambda

Facebook

WAF

Lambda

Administrator


- Report (cron)

SNS

Administrator



- レポート


データは、 API Gateway + Lambda を経由して DynamoDBへLambda は Python を使用

45

Lambda

Kinesis Firehose

Cloud Front

API Gateway

Cognito

DynamoDB

userclient

API

HTMLJS Image

認証

権限

S3

RedShift

Lambda

Facebook

WAF

Lambda

Administrator


- Report (cron)

SNS

Administrator



- レポート


DynamoDB に入った応募データはLambda から Firehose で S3経由Redshift へ

ただ、 Lambda コンテナ上の AWS SDK が古くて Firehose が呼び出せず実現せず。

46

Lambda

Kinesis Firehose

Cloud Front

API Gateway

Cognito

DynamoDB

userclient

API

HTMLJS Image

認証

権限

S3

RedShift

Lambda

Facebook

WAF

Lambda

Administrator


- Report (cron)

SNS

Administrator



- レポート


Lambda の定期実行（ CRON) を使って応募状況を SNS でレポート

47

テクノロジーの無駄遣い

48

報告会　兼おみやげ抽選会

49

報告会　兼おみやげ抽選会

50

Lambda コード抜粋（応募状況を返す API ）

Python で書いたらすごくシンプルに書けた！

51

やってみて良かったこと

新サービスをむりやり使う方針によってどんなサービスがあったか復習できた。想定ユースケースの確認ができた

新サービスを使ってみてサービスの概要を把握できた一回手を動かしてみることで、苦手意識が低下し

たLambda力が増したAPI Gateway が使えるようになったNode.js の辛さを再認識したPython に目覚めたサーバーレスアーキテクチャも行けそうな気がし

てきた

52

サーバーレスアーキテクチャについて

API Gateway の登場によりより現実感が増した。2 Tier アーキテクチャは用途が限定的なイメージデプロイ系はまだこなれてない開発方法、運用方法についてノウハウの蓄積が必要デプロイ手法の確立 (JAWS framework など )ブラウザでポチポチするのは辛い。ログまわり (CloudwatchLogs辛い）

認証まわりがまだふわっとしてる（自分の中で）うまくいけばコストダウンになりそう

53

新しい技術を学ぶのには“しばり”があると面白い

新サービスしばり

EC2 レスしばり

Lambdaしばり

54




55

• EC2 レス• マネージドシステムのフル活用

• DynamoDB 、 Cognito 、 SQS 、 S3 、 STS…• Lambda + API Gateway の採用

東急ハンズのポイントシステムを　 AWS フルマネージドで構築する作業を進めています。

特徴

56

新ポイントシステム基盤 AWS 全体構成

56

57

まとめ

クラウドはものすごい速さで進化している。　いままでのやり方が、少しすれば古いやり方に

次々と新しい概念や仕組みが現れるので、勉強して自分たちもシステムも成長させよう。

58

まとめ

大変なことも多いけど、自分たちの頭で考えてシステムを作っていくのは楽しい。

AWS の勉強会は各地で行われています。困ったら相談しよう。（相談に乗ってください）

一緒にクラウドのよりよい活用方法を考えて行きましょう！

59

ご静聴ありがとうございました。

Do It Yourself

Technology

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