Copyright © 2015. All rights reserved.
2015年2月7日
JAWS-UG KANSAI 特別編
ハンズラボ株式会社 田部井一成
S3をDB利用ショッピングセンター向けポイントシステム
3
開発チームの経歴
東急ハンズの内製化を担当してきた
元店員が開発主担当 RDB?オブジェクト指向?
ユニケージ開発手法 言語はbash
データはテキストファイルで保持 ミドルウェアやパッケージを極力排除
フロントエンドはHTML
4
案件概要
関東に5店舗、他に2店舗のショッピングモール ポイントカードの当初展開は3店舗。順次拡大予定。 300テナント以上でポイントが付与される
店舗リニューアルオープンにあわせて、ポイントカードを開始
5
2013年 第1弾ポイントシステム
Linux on EC2
• c3.2xlarge *2台• EBS 1TB (PIOPS:2800)
ユニケージ開発手法• bashスクリプト+テキストファイル• 正副構成→rsync
クラウド化しました!• クラウドだからサーバ調達が楽• クラウドだからリソースも潤沢に使えて安い• クラウドだから落ちません
某ショッピングモール向けにポイントシステムを構築
AZ-a AZ-c
6
2013年 第1弾ポイントシステム
Linux on EC2
• c3.2xlarge *2台• EBS 1TB (PIOPS:2800)
ユニケージ開発手法• bashスクリプト+テキストファイル• 正副構成→rsync
クラウド化しました!• クラウドだからサーバ調達が楽• クラウドだからリソースも潤沢に使えて安い• クラウドだから落ちません
某ショッピングモール向けにポイントシステムを構築
AZ-a AZ-c
AWSに載せ替えただけ!
7
2013年 第1弾ポイントシステム
Linux on EC2
• c3.2xlarge *2台• EBS 1TB (PIOPS:2800)
ユニケージ開発手法• bashスクリプト+テキストファイル• 正副構成→rsync
クラウド化しました!• クラウドだからサーバ調達が楽• クラウドだからリソースも潤沢に使えて安い• クラウドだから落ちません
某ショッピングモール向けにポイントシステムを構築
AZ-a AZ-c
AWSに載せ替えただけ!
スケーラビリティ無し!PIOPSが高額!
8
2013年 第1弾ポイントシステム
Linux on EC2
• c3.2xlarge *2台• EBS 1TB (PIOPS:2800)
ユニケージ開発手法• bashスクリプト+テキストファイル• 正副構成→rsync
クラウド化しました!• クラウドだからサーバ調達が楽• リソースも潤沢に使えて安い• クラウドだから落ちません
某ショッピングモール向けにポイントシステムを構築
AZ-a AZ-c
AWSに載せ替えただけ!
OSが落ちた!
EC2メンテナンス対応!
スケーラビリティ無し!PIOPSが高額!
9
2013年 第1弾ポイントシステム
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!
安眠保証付!
( ˘ω˘)スヤァ…
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
2
3
4
期初データと差分データに分ける アプリからは差分データの上書き更新のみ
アプリデータと保存データに分ける アプリからは保存データの作成と、アプリデータの上書き更新のみ
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等は使用しない。(ミドルウェアの排除)
29
マネージドサービスの積極利用
Amazon SES
会員マイページから会員様へのメール送信(メールアドレス確認)に、SESを利用 メールサーバがマネージドサービスで済むなら最高! しかし、携帯キャリアメール宛の送信ができず(受信者がドメイン拒否してると、SuppressionList入りしてしまう)
現在は携帯キャリアメール宛はPostfix、その他はSES、と使い分け。
31
今後
S3データ量・料金の削減 古いテキストデータのGlacier化 アプリデータの低冗長化採用
近い将来のポイント付与リアルタイム化、会員増加によるアクセス増加対応 スケールアウトの自動化 S3オブジェクト名を分散し、レスポンス低下を防ぐ
インフラの自動化 自動テストの導入と、本番ソース適用の自動化
Top Related