Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

18,496 views

Published on

2015年2月7日 大阪で開催されたJAWS-UG KANSAI 特別編でしゃべったときのスライドです。

Published in: Technology

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

  1. 1. Copyright © 2015. All rights reserved. 2015年2月7日 JAWS-UG KANSAI 特別編 ハンズラボ株式会社 田部井一成 S3をDB利用 ショッピングセンター向けポイントシステム
  2. 2. 1 自己紹介  名前:田部井 一成  所属:ハンズラボ株式会社  担当:外販案件、特にポイントシステム  特技:シェル芸、電子工作  趣味:ビールクラフト、燻製、歩く、寝る  好きなAWSサービス:
  3. 3. 2 ご紹介する内容 ショッピングセンター向けポイントカード基盤システム  メインDBはS3  Immutable Infrastructure  マネージドサービスの積極利用
  4. 4. 3 開発チームの経歴 東急ハンズの内製化を担当してきた  元店員が開発主担当  RDB?オブジェクト指向?  ユニケージ開発手法  言語はbash  データはテキストファイルで保持  ミドルウェアやパッケージを極力排除  フロントエンドはHTML
  5. 5. 4 案件概要  関東に5店舗、他に2店舗のショッピングモール  ポイントカードの当初展開は3店舗。順次拡大予定。  300テナント以上でポイントが付与される  店舗リニューアルオープンにあわせて、ポイントカードを開始
  6. 6. 5 2013年 第1弾ポイントシステム  Linux on EC2 • c3.2xlarge *2台 • EBS 1TB (PIOPS:2800)  ユニケージ開発手法 • bashスクリプト+テキストファイル • 正副構成→rsync  クラウド化しました! • クラウドだからサーバ調達が楽 • クラウドだからリソースも潤沢に使えて安い • クラウドだから落ちません 某ショッピングモール向けにポイントシステムを構築 AZ-a AZ-c
  7. 7. 6 2013年 第1弾ポイントシステム  Linux on EC2 • c3.2xlarge *2台 • EBS 1TB (PIOPS:2800)  ユニケージ開発手法 • bashスクリプト+テキストファイル • 正副構成→rsync  クラウド化しました! • クラウドだからサーバ調達が楽 • クラウドだからリソースも潤沢に使えて安い • クラウドだから落ちません 某ショッピングモール向けにポイントシステムを構築 AZ-a AZ-c AWSに載せ替えただけ!
  8. 8. 7 2013年 第1弾ポイントシステム  Linux on EC2 • c3.2xlarge *2台 • EBS 1TB (PIOPS:2800)  ユニケージ開発手法 • bashスクリプト+テキストファイル • 正副構成→rsync  クラウド化しました! • クラウドだからサーバ調達が楽 • クラウドだからリソースも潤沢に使えて安い • クラウドだから落ちません 某ショッピングモール向けにポイントシステムを構築 AZ-a AZ-c AWSに載せ替えただけ! スケーラビリティ無し! PIOPSが高額!
  9. 9. 8 2013年 第1弾ポイントシステム  Linux on EC2 • c3.2xlarge *2台 • EBS 1TB (PIOPS:2800)  ユニケージ開発手法 • bashスクリプト+テキストファイル • 正副構成→rsync  クラウド化しました! • クラウドだからサーバ調達が楽 • リソースも潤沢に使えて安い • クラウドだから落ちません 某ショッピングモール向けにポイントシステムを構築 AZ-a AZ-c AWSに載せ替えただけ! OSが落ちた! EC2メンテナンス対応! スケーラビリティ無し! PIOPSが高額!
  10. 10. 9 2013年 第1弾ポイントシステム  Linux on EC2 • c3.2xlarge *2台 • EBS 1TB (PIOPS:2800)  ユニケージ開発手法 • bashスクリプト+テキストファイル • 正副構成→rsync  クラウド化しました! • クラウドだからサーバ調達が楽 • リソースも潤沢に使えて安い • クラウドだから落ちません 某ショッピングモール向けにポイントシステムを構築 AZ-a AZ-c AWSに載せ替えただけ! OSが落ちた! メンテナンス対応! スケーラビリティ無し! PIOPSが高額!
  11. 11. 10 2014年 第2弾への改善方針① 高可用性、耐障害性  システムに何が起きても業務は継続  通常業務時間内に余裕の対応  メンテナンスやバージョンアップでの対応無し Immutable Infrastructure!
  12. 12. 11 2014年 第2弾への改善方針① 高可用性、耐障害性  システムに何が起きても業務は継続  通常業務時間内に余裕の対応  メンテナンスやバージョンアップでの対応無し Immutable Infrastructure! 安眠保証付! ( ˘ω˘)スヤァ…
  13. 13. 12 2014年 第2弾への改善方針② スケーラブル、でもユニケージ  今後の店舗展開を考慮し、何もしなくても高負荷に対応  ただしデータ構造は変えたくない S3をDBに!
  14. 14. 13 2014年 第2弾への改善方針③ マネージドサービスの積極利用  運用の負担を減らし、インフラコストの削減 DynamoDB CloudWatch Amazon SNSAmazon SES
  15. 15. 14 システム図 アプリデータ Bucket Amazon SES メール送信 Amazon SNS 処理エラー通知 管理者 会員 Internet 金券発券機 マイページWEBサーバ Internet 保存データ Bucket ポイント基盤サーバ Internet 管理画面WEB マイページAPI ポイント取引API ユーザー WEB アプリ データ セッション DynamoDB
  16. 16. 15 S3の採用 スケーラブルで、将来のデータ増にも簡 単に対応できるしメンテナンスフリーで安 心安全、そのうえbashから簡単に保存で きて、rsyncも不要、しかも安価なデータ ベースってないのかなぁ そんな夢のようなプロダクトなんて・・・ S3を使えばいいん じゃない
  17. 17. 16 S3の採用 スケーラブルで、将来のデータ増にも簡 単に対応できるしメンテナンスフリーで安 心安全、そのうえbashから簡単に保存で きて、rsyncも不要、しかも安価なデータ ベースってないのかなぁ そんな夢のようなプロダクトなんて・・・ S3を使えばいいん じゃない S3を使えばいいんじゃない!
  18. 18. 17 S3を使えばいいじゃない!! エンタープライズなリテールシステムでS3?  トランザクション処理が無いじゃん!危険すぎる!  整合性は?結果整合性?お客様の取引データに欠 落が無いと保証できるの?  コンテンツ配信に使うものでしょ?  バックアップになら使ってもいいよ。だがDBテメーは ダメだ
  19. 19. 18 S3を使えばいいじゃない!! エンタープライズなリテールシステムでS3?  トランザクション処理が無いじゃん!危険すぎる!  整合性は?結果整合性?お客様の取引データに欠 落が無いと保証できるの?  コンテンツ配信に使うものでしょ?  バックアップになら使ってもいいよ。だがDBテメーは ダメだ テキストファイルでシステム構築してきた経験を活かせ ば、S3でもDBできるよ!やったね!
  20. 20. 19 ちゃんとした理由  S3採用の理由  テキストファイル管理のデータ構造との親和性が高い  ポイントシステムは、ある会員データへ複数同時アクセスする可能性は低い(ポイ ントカードが起点のため)  取引履歴は、基本的に追記のみ。トランザクション処理は無くても大丈夫。  レスポンスはミリ秒単位である必要はない。(店舗オペレーションに極端な影響を 与えないレスポンスがあればOK)  DynamoDBやRDS、EBSに比べて、安い  結果整合性のS3でも対応可能と判断  結果整合性によりアプリデータにレコードの漏れ(前回取引反映前の上書き) が発生しても、継続チェック処理でリカバリ可能(数十秒以内)  とりあえず全ての取引を保存しておく  データが無くならない安心感  どれだけ投げてもスケールする  DynamoDBのようにスループットを気にしなくても良い  EBSやRDSのように保存容量を気にしなくても良い  日次単位でデータを整理する(ユニケージの応用)ことで、大量オブジェクトの氾濫 は避けられる。必要なデータをピンポイントで指定して取得可能。
  21. 21. 20 S3利用イメージ① アプリケーション 取引保存用 1取引1ファイル 取引履歴参照用 1会員1ファイル ポイント数参照用 1会員1ファイル APIを提供するapache 保有ポイン トは? 付与履歴 は? お買物券を発行したい! 1 2 3 4  期初データと差分データに分ける  アプリからは差分データの上書き更新のみ  アプリデータと保存データに分ける  アプリからは保存データの作成と、アプリデータの上書き更新のみ
  22. 22. 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
  23. 23. 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を使い、テキストファイル管理でもスケールするサーバ構成となっ た
  24. 24. 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の起動コスト
  25. 25. 24 AWS-CLIの起動コスト [hands@ip-10-33-0-207 ~]$ time aws s3 ls real 0m0.772s user 0m0.220s sys 0m0.020s [hands@ip-10-33-0-207 ~]$ time aws real 0m0.183s user 0m0.172s sys 0m0.004s [hands@ip-10-33-0-207 ~]$ time s3cmd ls real 0m0.400s user 0m0.080s sys 0m0.008s [hands@ip-10-33-0-207 ~]$ time s3cmd real 0m0.088s user 0m0.080s sys 0m0.004s aws-cliとs3cmd、同じPythonなのに、 倍の時間がかかる awsコマンドは起動コストが高い? 高速化を切実に希望!
  26. 26. 25 イミュータブルへの挑戦  メンテナンス時の再起動タイミングの調整がつらい  OSのダウンで障害対応  ソースリリースのための夜間対応  過去データ、ゴミデータによるリソースの圧迫→掃除がつらい イミュータブルの考え方を導入して、 毎日新しい環境を自動構築できれば解決! あとイミュータブルができちゃったらちょっとカッコいい
  27. 27. 26 イミュータブル化のポイント  サーバ停止時の対応が楽  AutoScalingによる自動再起動で、不意の停止の自動復旧  メンテナンス等も日次で新しいサーバが立ち上がるため、回避される  イミュータブルとするには、新環境立ち上げの際に、前日環境と新環境が併存す る時間がある。結果として、新環境での処理エラーが発生しても、前日環境で店舗 オペレーションが可能  夜間のエラーに怯えなくて良くなった!翌日ゆっくり対応します  リリース手順が楽  ステージング環境(兼テスト環境)へのソースの反映は、日次で新サーバへ毎日デ プロイ。テスト環境構築の手間が無い  本番環境へは、ステージングでテスト済みのソース一式(tar)をS3へ設置するだけ 。翌日自動デプロイ  EBS削減によるコスト減  消えたら困るデータをS3へ逃す設計となるので、エフェメラルディスクとS3を中心 に使うことに  EBSはOSイメージ、起動スクリプト、ログファイルのみの保存。30GB  ログファイルはサーバTerminate時に、終了スクリプトでS3へ保存する。  流用元システムでは、root:100GB data:500GB〜1TB(PIOPS 2800)
  28. 28. 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. 29. 28 マネージドサービスの積極利用 DynamoDB 会員マイページのセッション保存にはDynamoDBを利 用  WEBからは想定外のアクセス増大があり得るので、 DynamoDBを採用
  30. 30. 29 マネージドサービスの積極利用 Amazon SES 会員マイページから会員様へのメール送信(メールアドレス確認 )に、SESを利用  メールサーバがマネージドサービスで済むなら最高!  しかし、携帯キャリアメール宛の送信ができず(受信者がドメ イン拒否してると、SuppressionList入りしてしまう)  現在は携帯キャリアメール宛はPostfix、その他はSES、と使 い分け。
  31. 31. 30 マネージドサービスの積極利用 Amazon SNS 運用メンバーの通知にはSNSを利用。メール送信。 監視はCloudWatchを利用。サードパーティツールは使わ ない方針 CloudWatch
  32. 32. 31 今後 S3データ量・料金の削減  古いテキストデータのGlacier化  アプリデータの低冗長化採用 近い将来のポイント付与リアルタイム化、会員増加によるアクセス増 加対応  スケールアウトの自動化  S3オブジェクト名を分散し、レスポンス低下を防ぐ インフラの自動化  自動テストの導入と、本番ソース適用の自動化
  33. 33. 32 今後 EC2コストの削減  更新処理のLambda利用  スポットインスタンスの活用 分析の拡大  RedshiftやEMRの活用 システムのパッケージ化と展開

×