Copyright © 2015. All rights reserved.

2015年2月7日

JAWS-UG KANSAI 特別編

ハンズラボ株式会社 田部井一成

S3をDB利用ショッピングセンター向けポイントシステム

1

自己紹介

名前：田部井 一成所属：ハンズラボ株式会社担当：外販案件、特にポイントシステム

特技：シェル芸、電子工作趣味：ビールクラフト、燻製、歩く、寝る

好きなAWSサービス：

2

ご紹介する内容

ショッピングセンター向けポイントカード基盤システム

メインDBはS3

Immutable Infrastructure

マネージドサービスの積極利用

3

開発チームの経歴

東急ハンズの内製化を担当してきた

元店員が開発主担当 RDB？オブジェクト指向？

ユニケージ開発手法 言語はbash

データはテキストファイルで保持 ミドルウェアやパッケージを極力排除

フロントエンドはHTML

4

案件概要

関東に5店舗、他に2店舗のショッピングモール ポイントカードの当初展開は3店舗。順次拡大予定。 300テナント以上でポイントが付与される

店舗リニューアルオープンにあわせて、ポイントカードを開始

5

2013年 第１弾ポイントシステム

Linux on EC2

• c3.2xlarge *2台• EBS 1TB （PIOPS:2800）

ユニケージ開発手法• bashスクリプト＋テキストファイル• 正副構成→rsync

クラウド化しました！• クラウドだからサーバ調達が楽• クラウドだからリソースも潤沢に使えて安い• クラウドだから落ちません

某ショッピングモール向けにポイントシステムを構築

AZ-a AZ-c

6

2013年 第１弾ポイントシステム

Linux on EC2

• c3.2xlarge *2台• EBS 1TB （PIOPS:2800）

ユニケージ開発手法• bashスクリプト＋テキストファイル• 正副構成→rsync

クラウド化しました！• クラウドだからサーバ調達が楽• クラウドだからリソースも潤沢に使えて安い• クラウドだから落ちません

某ショッピングモール向けにポイントシステムを構築

AZ-a AZ-c

AWSに載せ替えただけ！

7

2013年 第１弾ポイントシステム

Linux on EC2

• c3.2xlarge *2台• EBS 1TB （PIOPS:2800）

ユニケージ開発手法• bashスクリプト＋テキストファイル• 正副構成→rsync

クラウド化しました！• クラウドだからサーバ調達が楽• クラウドだからリソースも潤沢に使えて安い• クラウドだから落ちません

某ショッピングモール向けにポイントシステムを構築

AZ-a AZ-c

AWSに載せ替えただけ！

スケーラビリティ無し！PIOPSが高額！

8

2013年 第１弾ポイントシステム

Linux on EC2

• c3.2xlarge *2台• EBS 1TB （PIOPS:2800）

ユニケージ開発手法• bashスクリプト＋テキストファイル• 正副構成→rsync

クラウド化しました！• クラウドだからサーバ調達が楽• リソースも潤沢に使えて安い• クラウドだから落ちません

某ショッピングモール向けにポイントシステムを構築

AZ-a AZ-c

AWSに載せ替えただけ！

OSが落ちた!

EC2メンテナンス対応！

スケーラビリティ無し！PIOPSが高額！

9

2013年 第１弾ポイントシステム

Linux on EC2

• c3.2xlarge *2台• EBS 1TB （PIOPS:2800）

ユニケージ開発手法• bashスクリプト＋テキストファイル• 正副構成→rsync

クラウド化しました！• クラウドだからサーバ調達が楽• リソースも潤沢に使えて安い• クラウドだから落ちません

某ショッピングモール向けにポイントシステムを構築

AZ-a AZ-c

AWSに載せ替えただけ！

OSが落ちた!

メンテナンス対応！

スケーラビリティ無し！PIOPSが高額！

10

2014年 第2弾への改善方針①

高可用性、耐障害性

システムに何が起きても業務は継続 通常業務時間内に余裕の対応 メンテナンスやバージョンアップでの対応無し

Immutable Infrastructure!

11

2014年 第2弾への改善方針①

高可用性、耐障害性

システムに何が起きても業務は継続 通常業務時間内に余裕の対応 メンテナンスやバージョンアップでの対応無し

Immutable Infrastructure!

安眠保証付！

( ˘ω˘)ｽﾔｧ…

12

2014年 第2弾への改善方針②

スケーラブル、でもユニケージ

今後の店舗展開を考慮し、何もしなくても高負荷に対応 ただしデータ構造は変えたくない

S3をDBに！

13

2014年 第2弾への改善方針③

マネージドサービスの積極利用

運用の負担を減らし、インフラコストの削減

DynamoDB CloudWatch Amazon SNSAmazon SES

14

システム図

アプリデータBucket

Amazon SES

ﾒｰﾙ送信

Amazon SNS

処理ｴﾗｰ通知

管理者 会員

Internet

金券発券機

ﾏｲﾍﾟｰｼﾞWEBｻｰﾊﾞ

Internet

保存データBucket

ﾎﾟｲﾝﾄ基盤ｻｰﾊﾞ

Internet

管理画面WEB ﾏｲﾍﾟｰｼﾞAPI ﾎﾟｲﾝﾄ取引API

ユーザー

WEB

アプリ

データ

セッションDynamoDB

15

S3の採用

スケーラブルで、将来のデータ増にも簡単に対応できるしメンテナンスフリーで安心安全、そのうえbashから簡単に保存できて、rsyncも不要、しかも安価なデータベースってないのかなぁ

そんな夢のようなプロダクトなんて・・・

S3を使えばいいんじゃない

16

S3の採用

スケーラブルで、将来のデータ増にも簡単に対応できるしメンテナンスフリーで安心安全、そのうえbashから簡単に保存できて、rsyncも不要、しかも安価なデータベースってないのかなぁ

そんな夢のようなプロダクトなんて・・・

S3を使えばいいんじゃない

S3を使えばいいんじゃない！

17

S3を使えばいいじゃない！！

エンタープライズなリテールシステムでS3？ トランザクション処理が無いじゃん！危険すぎる！

整合性は？結果整合性？お客様の取引データに欠落が無いと保証できるの？

コンテンツ配信に使うものでしょ？ バックアップになら使ってもいいよ。だがDBテメーはダメだ

18

S3を使えばいいじゃない！！

エンタープライズなリテールシステムでS3？ トランザクション処理が無いじゃん！危険すぎる！

整合性は？結果整合性？お客様の取引データに欠落が無いと保証できるの？

コンテンツ配信に使うものでしょ？ バックアップになら使ってもいいよ。だがDBテメーはダメだ

テキストファイルでシステム構築してきた経験を活かせば、S3でもDBできるよ！やったね！

19

ちゃんとした理由

S3採用の理由 テキストファイル管理のデータ構造との親和性が高い ポイントシステムは、ある会員データへ複数同時アクセスする可能性は低い（ポイントカードが起点のため）

取引履歴は、基本的に追記のみ。トランザクション処理は無くても大丈夫。 レスポンスはミリ秒単位である必要はない。（店舗オペレーションに極端な影響を与えないレスポンスがあればOK）

DynamoDBやRDS、EBSに比べて、安い 結果整合性のS3でも対応可能と判断

結果整合性によりアプリデータにレコードの漏れ（前回取引反映前の上書き）が発生しても、継続チェック処理でリカバリ可能（数十秒以内）

とりあえず全ての取引を保存しておく データが無くならない安心感 どれだけ投げてもスケールする DynamoDBのようにスループットを気にしなくても良い EBSやRDSのように保存容量を気にしなくても良い 日次単位でデータを整理する（ユニケージの応用）ことで、大量オブジェクトの氾濫は避けられる。必要なデータをピンポイントで指定して取得可能。

20

S3利用イメージ① アプリケーション

取引保存用1取引1ファイル

取引履歴参照用1会員1ファイル

ポイント数参照用1会員1ファイル

APIを提供するapache

保有ポイントは？

付与履歴は？

お買物券を発行したい！

1

２

３

４

期初データと差分データに分ける アプリからは差分データの上書き更新のみ

アプリデータと保存データに分ける アプリからは保存データの作成と、アプリデータの上書き更新のみ

21

S3利用イメージ② 日次処理

取引保存用1取引1ファイル

アプリ参照用1会員1ファイル

1日1回起動するバッチサーバ

日別取引ファイル全履歴ファイル

アプリが保存した差分データから、1日のまとめデータを作る まとめデータから、翌日用期初データを作る

つまるところ、単にユニケージのテキスト管理の応用 詳しくはWEBで！

• UEC https://uec.usp-lab.com/

• ハンズラボ技術ブログ https://www.hands-lab.com/tech/entry/62.html

22

ベンチマーク

同時ﾘｸｴｽﾄ件数

1台 2台 4台 8台 12台

1 0.66 0.58 0.66 0.62 0.59

5 2.21 1.85 1.62 1.83 1.70

10 4.25 2.65 2.02 2.06 1.93

50 21.71 11.64 7.59 4.64 3.59

100 42.95 22.42 12.17 7.41 5.77

500 N/A N/A 55.79 26.0 14.99

アプリサーバ台数毎の最大レスポンス秒数

同一VPCの別インスタンスから実行 60秒以内のレスポンスが無ければエラー（N/A） アプリサーバはc3.xlargeインスタンスを使用

S3を使い、テキストファイル管理でもスケールするサーバ構成となった

23

ベンチマーク

同時ﾘｸｴｽﾄ件数

1台 2台 4台 8台 12台

1 0.66 0.58 0.66 0.62 0.59

5 2.21 1.85 1.62 1.83 1.70

10 4.25 2.65 2.02 2.06 1.93

50 21.71 11.64 7.59 4.64 3.59

100 42.95 22.42 12.17 7.41 5.77

500 N/A N/A 55.79 26.0 14.99

アプリサーバ台数毎の最大レスポンス秒数

最小レスポンスタイムはそこそこ プロセスが大量に生成されるbashCGIの特性 aws-cliの起動コスト

24

AWS-CLIの起動コスト

[hands@ip-10-33-0-207 ~]$ time aws s3 lsreal 0m0.772suser 0m0.220ssys 0m0.020s

[hands@ip-10-33-0-207 ~]$ time awsreal 0m0.183suser 0m0.172ssys 0m0.004s

[hands@ip-10-33-0-207 ~]$ time s3cmd lsreal 0m0.400suser 0m0.080ssys 0m0.008s

[hands@ip-10-33-0-207 ~]$ time s3cmdreal 0m0.088suser 0m0.080ssys 0m0.004s

aws-cliとs3cmd、同じPythonなのに、倍の時間がかかる

awsコマンドは起動コストが高い？高速化を切実に希望！

25

イミュータブルへの挑戦

メンテナンス時の再起動タイミングの調整がつらい OSのダウンで障害対応 ソースリリースのための夜間対応 過去データ、ゴミデータによるリソースの圧迫→掃除がつらい

イミュータブルの考え方を導入して、毎日新しい環境を自動構築できれば解決！

あとイミュータブルができちゃったらちょっとカッコいい

26

イミュータブル化のポイント

サーバ停止時の対応が楽 AutoScalingによる自動再起動で、不意の停止の自動復旧 メンテナンス等も日次で新しいサーバが立ち上がるため、回避される イミュータブルとするには、新環境立ち上げの際に、前日環境と新環境が併存する時間がある。結果として、新環境での処理エラーが発生しても、前日環境で店舗オペレーションが可能 夜間のエラーに怯えなくて良くなった！翌日ゆっくり対応します

リリース手順が楽 ステージング環境（兼テスト環境）へのソースの反映は、日次で新サーバへ毎日デプロイ。テスト環境構築の手間が無い

本番環境へは、ステージングでテスト済みのソース一式（tar）をS3へ設置するだけ。翌日自動デプロイ

EBS削減によるコスト減 消えたら困るデータをS3へ逃す設計となるので、エフェメラルディスクとS3を中心に使うことに

EBSはOSイメージ、起動スクリプト、ログファイルのみの保存。30GB

ログファイルはサーバTerminate時に、終了スクリプトでS3へ保存する。 流用元システムでは、root:100GB data:500GB〜1TB(PIOPS 2800)

27

環境構築処理フロー

inid.d

本番ﾃﾞﾌﾟﾛｲ

ﾊﾞｯﾁｻｰﾊﾞ起動

日次ﾃﾞｰﾀ処理

WEBサーバASGのDesired

をx2

WEBｻｰﾊﾞ起動確認/ELB

Healthy確認

WEBサーバASGのDesired

を÷2

ﾊﾞｯﾁｻｰﾊﾞ停止

ﾊﾞｯﾁｻｰﾊﾞ用のAutoScalingGroupを、時間起動でDesiredを1にする。

Linux起動ｽｸﾘﾌﾟﾄで、ｴﾌｪﾒﾗﾙﾃﾞｨｽｸの初期化(RAID0)

EC2ｲﾝｽﾀﾝｽのTagを取得し、Tagに対応した設定ﾌｧｲﾙとｿｰｽをS3から取得、展開

日次処理実行（前頁）

WEBサーバのAutoScalingGroupは、TerminationポリシーをOldest

にしておく

古いサーバのTerminate

AutoScalingGroupのDesired

を0にする。

AutoScalingGroupと、インスタンスTag、Linuxのinit.d処理で実装！• Chef等は使用しない。（ミドルウェアの排除）

28

マネージドサービスの積極利用

DynamoDB

会員マイページのセッション保存にはDynamoDBを利用WEBからは想定外のアクセス増大があり得るので、

DynamoDBを採用

29

マネージドサービスの積極利用

Amazon SES

会員マイページから会員様へのメール送信（メールアドレス確認）に、SESを利用 メールサーバがマネージドサービスで済むなら最高！ しかし、携帯キャリアメール宛の送信ができず（受信者がドメイン拒否してると、SuppressionList入りしてしまう）

現在は携帯キャリアメール宛はPostfix、その他はSES、と使い分け。

30

マネージドサービスの積極利用

Amazon SNS

運用メンバーの通知にはSNSを利用。メール送信。監視はCloudWatchを利用。サードパーティツールは使わない方針

CloudWatch

31

今後

S3データ量・料金の削減 古いテキストデータのGlacier化 アプリデータの低冗長化採用

近い将来のポイント付与リアルタイム化、会員増加によるアクセス増加対応 スケールアウトの自動化 S3オブジェクト名を分散し、レスポンス低下を防ぐ

インフラの自動化 自動テストの導入と、本番ソース適用の自動化

32

今後

EC2コストの削減更新処理のLambda利用スポットインスタンスの活用

分析の拡大RedshiftやEMRの活用

システムのパッケージ化と展開