面倒なのでちゃちゃっとお腹を満たすには、中華料理屋に行って食べる。これはラーメンを作るというサービスを提供してくれるASPを利用するみたいな感じ。と沢山たのんでシェアするといろいろ食べられて、お値段も安く満足度高い。こんな感じで、みんなでちょっとずつリソースを分け合って安く上げるようにしてくれる仕組みがクラウド。大人数でシェアできるようになってくると、「ちょっとずつ」の部分がもっと細分化できるようになってきて、「俺は20円払うから酢豚に入ったパイナップル1カケだけ食いたい」みたいなワガママな要望にも応えられるようになってくる。それが、Lambdaとか、ECSみたいな更に小さい単位でのリソースのシェアの形。シェアする人が多ければ多いほど、いろんなシェアの形が生まれてきます。AWS利用者はどんどん増えており、さらに新しいシェアの形がうまれる可能性もどんどん増えています。眠くて何を書いているか良く分からなくなってきましたが、明日、どんなサービスがリリースされるか、今から楽しみです!Pocketネットストアのセールに向けて行った負荷対策についてAWS2015年10月1日ハンズラボPocketこんにちは、井上です。東急ハンズでは8月26日〜9/2にハンズメッセというセールを開催しました。今日はそれに向けて行った、ネットストアの負荷対策の内容を紹介したいと思います。システムの負荷対策の取り組みとしては、長期にわたるシステムの改善と、直前の対応があるのですが、今回は直前の対応について紹介します。(1)負荷試験準備まずは負荷試験をするための準備を行いました。負荷試験を実施するにあたり、まずは負荷試験を実施する環境のELBの暖機運転(Pre-Warming)の申請を行いました。ELBは急激なスパイクアクセス時にスケールするのに時間がかかるため、予めアクセス増加が分かっている場合には事前に申請しておきます。下記のような内容をまとめて、AWSのサポートセンターより申請を行います。イベント日までにバックエンドEC2インスタンス数を増やしますか。イベント日までにバックエンドEC2インスタンス数を増やしますか。(増やす場合はいつ、どのくらい増やしますか)ELBはKeep-Aliveが有効になっていた方がスループットが出るとのことで、有効にすることをおすすめされました。長期的なシステム改善により、ほとんどのリクエストはElasticBeanstalkで動作しオートスケールするシステムで処理するようになっているのですが、一部、スケールできない構造のシステムが残ってしまっています。そのシステムについては、スケールアップの対応を行いました。仮想化方式が、PV(paravirtual)でインスタンスタイプの選択肢にも制限があったため、HVMに変換を行いました。システムの構築方法が明文化されていれば、変換せずに新インスタンスを立ち上げてそちらに構築しなおせば良いのですが、構築方法が不明で秘伝のタレのようなインスタンスになってしまっているため、諦めて変換を行いました。実施については下記を参考にしました。通常の開発環境とは別で負荷試験用の環境を用意し、各種準備を行いました。事前に昨年のセール時のアクセスログを集計し、テストシナリオを調整しました。協力のもと、Jmeterを用いた負荷試験を実施しました。80スレッド、合計3840スレッドでの試験まで実施しました。発生した問題点のほとんど(80%以上)が、スケールできないシステムに起因する問題でした。起きた問題を分析、対応を行い、再テストを繰り返しました。一部ですが、下記のような対応を行いました。コマンドが立ち上がりプロセス過多になる現象が発生しました。awsコマンドはPythonで記述されていて起動自体が重く、リアルタム処理には耐えられないと判断し、非同期で処理を行うように改修しました。処理中にタイムアウトしてエラー画面になってしまう現象が多発しました。システムのレイヤーが多段に重なりあっているため、どのシステムでタイムアウトエラーを出しているのかの調査を行い、タイムアウト時間の調整を行いました。各レイヤー毎に、ELB、apache(mod_proxy)、mod_php、mod_cgiなど各所にタイムアウト設定があるためどこの設定が効いてタイムアウトになっているのか、調査に時間がかかってしまいました。同時リクエスト数が増えると負荷に耐えられないため、可能な限りキャッシュを使うように改修しました。ネットストアのポイントについては、商品を発送しないとポイントが付与されないため、出荷作業を行わないセール当日についてはポイント情報を事前にキャッシュに乗せて処理するように改修を行いました。負荷試験を乗り切った各種システムの設定値などをまとめ、本番環境に適用しました。チェックリストを作成し、きちんと本番に反映されているかどうかの確認を行いました。結果としては、準備の甲斐もあり、大きなトラブルもなくセールを終えることができ、ネットストア売上としては過去最高の売上を上げることができました。セール開始直後に人が押し寄せている状態また、これは負荷対策とは別なのですが、昨年は深夜00:00だったセール開始時間を今年は18:00に変更しました。18:00開始で、つながりにくい状況も発生しなかったため、開始後のピークを過ぎても長い時間お買い物していただける状況を維持することができました。この辺りも売上アップへつながった要因ではないかと思います。オレンジの線が2014年、青の線が2015年です。ピークのアクセス数は昨年より落ちましたが、ピークを過ぎた後も継続的にアクセスされました。まとめ大掛かりなセールなどの、急激なアクセス増加に対応するには、事前に実際の状況に近いテストがどこまで実施できるかがポイントだと感じました。AWSを使っていると、簡単に台数を増やしたり、減らしたり、柔軟にテストが実施できるので良いですね。AWSにもいろいろな所に上限が設けられているので、予めその上限を知るためにも事前にテストしておく事が重要です。下記のようなものです。大量にインスタンスを立ち上げようとしたら、インスタンス数の上限にひかかって立ちあげられなかった。ような一般的なインスタンスタイプは上限が多めに設定されていますが、マイナーなインスタンスタイプの場合、かなり少なく設定されていることがあります。ElasticBeanstalkでデプロイしようとしたら作れるセキュリティグループ数の上限にかかってデプロイに失敗したオートスケールでスケールできると思っていたが、サブネットのIPアドレスが枯渇したインスタンスを誰かが大量に買い占めていて立ち上がらなかったDynamoDBのスループットを上げようとしたが、上限の20,000に達していて上げられなかった。Elasticache/memcachedに5つ以上のノードを一度に追加したらエラーになることがあった。ものは、事前に試して経験していれば、上限緩和申請やその他回避策を講じて対応することができます。AWSの不具合に遭遇することもありますが、事前に経験していれば、その機能を使わないなど、回避することが出来ます。何かあった場合に備えて、下記の本を読みました。必要にならずに良かったです。勉強会2015年9月4日ハンズラボPocket加藤です。ビッグデータによるビジネス革新手法に参加してきましたのでレポート致します。AWS系のイベントは業界的な事もあってかラフな方が多い印象なのですが、今回のイベントはスーツの方が多くいらっしゃいました。平日フルにもかかわらず常に8割程度埋まっており注目の高さが伺えました。驚いたのはスライドをカメラを取る人がいなかった事!資料を後で共有する常にアナウンスしていたのが効果的だったのでしょうか。́)キリッ本題ですが、皆さんが一様におっしゃっていたのは、データだけ渡して分析してねと言うのは失敗ケースと強調されていました。分析する際は段階を追って進まないと失敗するのに、ひとっ飛びするパターンが多いそうです。個人的にBIツールまで持っていければガラガラポンできそうな気がしてましたが、一発で革新なんて考えない方が良いですね。専門的な統計学や経験等のパターン等はあると思いますが。現場・システム・経営等々の横断的なチームで分担ではなく協力、運用してブラッシュアップしていくのが大事そうです。データサイエンティストがいれば最強ですが今は引く手数多でしょう。データをグリグリしているとデータ間のインスピレーションが増すそうです。なんとなくこのデータを付け合わせればこうなる気がするみたいな。いう時は良い結果につながる事のが多いそうです。