Transcript

• 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
• 16. 15 S3の採用 スケーラブルで、将来のデータ増にも簡 単に対応できるしメンテナンスフリーで安 心安全、そのうえbashから簡単に保存で きて、rsyncも不要、しかも安価なデータ ベースってないのかなぁ そんな夢のようなプロダクトなんて・・・ S3を使えばいいん じゃない
• 17. 16 S3の採用 スケーラブルで、将来のデータ増にも簡 単に対応できるしメンテナンスフリーで安 心安全、そのうえbashから簡単に保存で きて、rsyncも不要、しかも安価なデータ ベースってないのかなぁ そんな夢のようなプロダクトなんて・・・ S3を使えばいいん じゃない S3を使えばいいんじゃない！
• 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)
• 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. 28 マネージドサービスの積極利用 DynamoDB 会員マイページのセッション保存にはDynamoDBを利 用  WEBからは想定外のアクセス増大があり得るので、 DynamoDBを採用
• 30. 29 マネージドサービスの積極利用 Amazon SES 会員マイページから会員様へのメール送信（メールアドレス確認 ）に、SESを利用  メールサーバがマネージドサービスで済むなら最高！  しかし、携帯キャリアメール宛の送信ができず（受信者がドメ イン拒否してると、SuppressionList入りしてしまう）  現在は携帯キャリアメール宛はPostfix、その他はSES、と使 い分け。
• 31. 30 マネージドサービスの積極利用 Amazon SNS 運用メンバーの通知にはSNSを利用。メール送信。 監視はCloudWatchを利用。サードパーティツールは使わ ない方針 CloudWatch
• 32. 31 今後 S3データ量・料金の削減  古いテキストデータのGlacier化  アプリデータの低冗長化採用 近い将来のポイント付与リアルタイム化、会員増加によるアクセス増 加対応  スケールアウトの自動化  S3オブジェクト名を分散し、レスポンス低下を防ぐ インフラの自動化  自動テストの導入と、本番ソース適用の自動化
• 33. 32 今後 EC2コストの削減  更新処理のLambda利用  スポットインスタンスの活用 分析の拡大  RedshiftやEMRの活用 システムのパッケージ化と展開