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