AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

re:Invent 2015 AWS新サービスまとめ

Pocket

1日目

1) Amazon QuickSight

  • BIツール
  • SPICE/高速な並列、インメモリのエンジン

2) Amazon Kinesis Firehose

3) SnowBall

4)Maria DB (RDS/DB Engine)

5) AWS Database Migration Service

  • 既存データベースからのAWS上のエンジンへの移行サービス
  • 今日から利用可能
  • マイグレーション以外のレプリケーションも可能

6) AWS SCHEMA CONVERSION TOOL

  • データベース間のスキーマを変換するツール
  • 今日から利用可能

AWS Config Rules

Amazon INSPECTOR

  • 自動化されたセキュリティアセスメント
  • セキリュティ的な問題をチェックしReportしてくれるサービス。

2日目

Amazon Kinesis Analytics

  • リアルタイムアナリティクス
  • SQL使える

EC2インスタンスアップデート(X1、 T2.Nano)

EC2 Instance Update – X1 (SAP HANA) & T2.Nano

X1

  • 2 TB 以上の memory
  • Four Intel® Xeon® E7 processors
  • 100 以上の vCPUs
  • 2016年 1Qリリース

AMAZON EC2 Container Registory

  • コンテナを商用環境で動かす最適な場所になる
  • スケジューラー
  • INTEGRATION WITH COMPOSE

Lambda アップデート

【AWS発表】AWS Lambdaのアップデート – Python, VPC, 実行時間の増加, スケジュールなど

  • VPC内にLambdaを配置
  • Python サポート
  • CRON 的な使い方ができるように
  • ファンクション実行時間の増加(最大5分まで)
  • ファンクションのバージョニング

Mobile Hub

AWS Mobile Hub – Build, Test, and Monitor Mobile Applications | AWS Official Blog

  • よくわからん

AWS IoT

全貌がよくわからないのでキーワードだけ…

【AWS発表】AWS IoT コネクテッドデバイス向けクラウドサービス

  • Device Gateway
  • Rules Engine
  • MQTT
  • New SDK (C/JS/arduino)

キーノート発表以外でリリースされたもの

  • Amazon Elasticsearch Service
  • Amazon RDS for Aurora 東京リージョン
  • Amazon API Gateway 東京リージョン
  • Amazon CloudWatch Dashboards

以上

Pocket

クラウドの本質はみんなでシェア

Pocket

こんにちは、井上です。

AWS re:Invent参加のため、ラスベガスに来ています。

本日、『GPS319 – Building Tomorrow’s Applications: Serverless Solutions in the Cloud』 というセッションを見て、風呂のなかでぼーっと考えた事を書いてみたいと思います。

考えた事というか、セッションの中でも「Compute Sharing=Lower Costs」みたいなことを言っていたのでそのまんまなのですが、クラウドとはみんなでリソースをシェアすることなんだなぁと改めて感じました。

例えば、家でラーメンが食べたいと思って、作って食べるには、調理器具とか、ガスとかの設備や材料を用意したりしないといけない。調理も自分。
これ、オンプレミス。

でも、面倒なのでちゃちゃっとお腹を満たすには、中華料理屋に行って食べる。これはラーメンを作るというサービスを提供してくれるASPを利用するみたいな感じ。

これでもとりあえずの欲求は満たせると思うのですが、大人数で行って、ラーメンと餃子とチャーハンと回鍋肉と酢豚と… と沢山たのんでシェアするといろいろ食べられて、お値段も安く満足度高い。 
こんな感じで、みんなでちょっとずつリソースを分け合って安く上げるようにしてくれる仕組みがクラウド。

で、さらにもっと大人数でシェアできるようになってくると、「ちょっとずつ」の部分がもっと細分化できるようになってきて、「俺は20円払うから酢豚に入ったパイナップル1カケだけ食いたい」みたいなワガママな要望にも応えられるようになってくる。
それが、Lambdaとか、ECSみたいな更に小さい単位でのリソースのシェアの形。

シェアする人が多ければ多いほど、いろんなシェアの形が生まれてきます。
AWS利用者はどんどん増えており、さらに新しいシェアの形がうまれる可能性もどんどん増えています。

眠くて何を書いているか良く分からなくなってきましたが、明日、どんなサービスがリリースされるか、今から楽しみです!

Pocket

ネットストアのセールに向けて行った負荷対策について

Pocket

こんにちは、井上です。

東急ハンズでは8月26日〜9/2にハンズメッセというセールを開催しました。今日はそれに向けて行った、ネットストアの負荷対策の内容を紹介したいと思います。

MESSE2015-Banner

システムの負荷対策の取り組みとしては、長期にわたるシステムの改善と、直前の対応があるのですが、今回は直前の対応について紹介します。

(1)負荷試験準備

まずは負荷試験をするための準備を行いました。

ELBのPre-Warming申請

負荷試験を実施するにあたり、まずは負荷試験を実施する環境のELBの暖機運転(Pre-Warming)の申請を行いました。
ELBは急激なスパイクアクセス時にスケールするのに時間がかかるため、予めアクセス増加が分かっている場合には事前に申請しておきます。

下記のような内容をまとめて、AWSのサポートセンターより申請を行います。

ELBはKeep-Aliveが有効になっていた方がスループットが出るとのことで、有効にすることをおすすめされました。

参考: [AWSマイスターシリーズ]Amazon Elastic Load Balancing (ELB)

インスタンスタイプの変更

長期的なシステム改善により、ほとんどのリクエストはElasticBeanstalkで動作しオートスケールするシステムで処理するようになっているのですが、一部、スケールできない構造のシステムが残ってしまっています。
そのシステムについては、スケールアップの対応を行いました。

まず、仮想化方式が、PV(paravirtual)でインスタンスタイプの選択肢にも制限があったため、HVMに変換を行いました。
システムの構築方法が明文化されていれば、変換せずに新インスタンスを立ち上げてそちらに構築しなおせば良いのですが、構築方法が不明で秘伝のタレのようなインスタンスになってしまっているため、諦めて変換を行いました。

実施については下記を参考にしました。(3〜4時間くらいかかりました)

AWSで仮想化方式 PV(paravirtual) の既存 CentOS AMIを HVMにする – Qiita

その他負荷試験環境の構築

通常の開発環境とは別で負荷試験用の環境を用意し、各種準備を行いました。

  • 負荷試験用Beanstalk環境の作成
  • 負荷試験用のElastiCacheの作成
  • 負荷試験用のDynamoDBのスループット調整

負荷試験のシナリオの作成

事前に昨年のセール時のアクセスログを集計し、テストシナリオを調整しました。

(2)負荷試験の実施

チームラボさん の協力のもと、Jmeterを用いた負荷試験を実施しました。
負荷をかける側も分散しないと十分な負荷がかけられないため、最終的には、48台のインスタンスでそれぞれ 80スレッド、合計3840スレッドでの試験まで実施しました。

(3)負荷試験を結果で明らかになったボトルネックの解消

発生した問題点のほとんど(80%以上)が、スケールできないシステムに起因する問題でした。
起きた問題を分析、対応を行い、再テストを繰り返しました。

一部ですが、下記のような対応を行いました。

awsコマンドのリアルタイム処理での使用を削減

リアルタイム処理中に aws コマンドでs3に接続している部分がネックとなり、大量のaws コマンドが立ち上がりプロセス過多になる現象が発生しました。
awsコマンドはPythonで記述されていて起動自体が重く、リアルタム処理には耐えられないと判断し、非同期で処理を行うように改修しました。
(goなどで書かれた起動の軽い実装があればと思い探したのですが、使えそうなものが見つかりませんでした)

タイムアウト問題への対応

処理中にタイムアウトしてエラー画面になってしまう現象が多発しました。
システムのレイヤーが多段に重なりあっているため、どのシステムでタイムアウトエラーを出しているのかの調査を行い、タイムアウト時間の調整を行いました。
各レイヤー毎に、ELB、apache(mod_proxy)、mod_php、mod_cgiなど各所にタイムアウト設定があるためどこの設定が効いてタイムアウトになっているのか、調査に時間がかかってしまいました。

キャッシュを使ったリクエストの削減

同時リクエスト数が増えると負荷に耐えられないため、可能な限りキャッシュを使うように改修しました。

例えば、ネットストアのポイントについては、商品を発送しないとポイントが付与されないため、出荷作業を行わないセール当日については
ポイント情報を事前にキャッシュに乗せて処理するように改修を行いました。

(4)本番環境の準備

負荷試験を乗り切った各種システムの設定値などをまとめ、本番環境に適用しました。
また、チェックリストを作成し、きちんと本番に反映されているかどうかの確認を行いました。

  • 本番環境のELBの Pre-Warming
  • DynamoDBのスループットの設定
  • ElasticBeanstalkのインスタンスタイプ、オートスケール設定
  • ElastiCache/redisのインスタンスタイプ、台数の設定
  • ElastiCache/memcachedのインスタンスタイプ、台数の設定

セールの結果

結果としては、準備の甲斐もあり、大きなトラブルもなくセールを終えることができ、ネットストア売上としては過去最高の売上を上げることができました。

GA_Summary_20150826_1806

※ セール開始直後に人が押し寄せている状態

また、これは負荷対策とは別なのですが、昨年は深夜00:00だったセール開始時間を今年は18:00に変更しました。
昨年は 00:00開始とともに、アクセスが集中し、つながりにくい状況になるとみんな諦めて寝てしまうという状況になってしまっていたのですが、今年は 18:00開始で、つながりにくい状況も発生しなかったため、開始後のピークを過ぎても長い時間お買い物していただける状況を維持することができました。
この辺りも売上アップへつながった要因ではないかと思います。

GA_PV_2014_vs_2015

※ オレンジの線が2014年、青の線が2015年です。ピークのアクセス数は昨年より落ちましたが、ピークを過ぎた後も継続的にアクセスされました。


まとめ

大掛かりなセールなどの、急激なアクセス増加に対応するには、事前に実際の状況に近いテストがどこまで実施できるかがポイントだと感じました。
AWSを使っていると、簡単に台数を増やしたり、減らしたり、柔軟にテストが実施できるので良いですね。

ただし、AWSにもいろいろな所に上限が設けられているので、予めその上限を知るためにも事前にテストしておく事が重要です。

たとえば下記のようなものです。

  • 大量にインスタンスを立ち上げようとしたら、インスタンス数の上限にひかかって立ちあげられなかった。
    • c3.large のような一般的なインスタンスタイプは上限が多めに設定されていますが、マイナーなインスタンスタイプの場合、かなり少なく設定されていることがあります。
  • ElasticBeanstalkでデプロイしようとしたら作れるセキュリティグループ数の上限にかかってデプロイに失敗した
  • オートスケールでスケールできると思っていたが、サブネットのIPアドレスが枯渇した
  • インスタンスを誰かが大量に買い占めていて立ち上がらなかった
  • DynamoDBのスループットを上げようとしたが、上限の20,000に達していて上げられなかった。
  • Elasticache/memcachedに5つ以上のノードを一度に追加したらエラーになることがあった。

大抵のものは、事前に試して経験していれば、上限緩和申請やその他回避策を講じて対応することができます。
また、AWSの不具合に遭遇することもありますが、事前に経験していれば、その機能を使わないなど、回避することが出来ます。

番外編

何かあった場合に備えて、下記の本を読みました。必要にならずに良かったです。

ITエンジニアのためのハイプレッシャー下での対応術
Amazon.co.jp: ITエンジニアのためのハイプレッシャー下での対応術: 鳥山 康見: 本

Pocket

AWSソリューションDays ビッグデータによるビジネス革新手法 参加レポート

Pocket

加藤です。

先日、AWSソリューションDays2015 Day2 ビッグデータによるビジネス革新手法に参加してきましたのでレポート致します。

AWS系のイベントは業界的な事もあってかラフな方が多い印象なのですが、今回のイベントはスーツの方が多くいらっしゃいました。
平日フルにもかかわらず常に8割程度埋まっており注目の高さが伺えました。
そして驚いたのはスライドをカメラを取る人がいなかった事!
資料を後で共有する常にアナウンスしていたのが効果的だったのでしょうか。
これを言い訳にする訳ではないですが、会場の写真はないです(`・ω・´)キリッ

本題ですが、皆さんが一様におっしゃっていたのは、
データだけ渡して分析してねと言うのは失敗ケースと強調されていました。
分析する際は段階を追って進まないと失敗するのに、ひとっ飛びするパターンが多いそうです。
個人的にBIツールまで持っていければガラガラポンできそうな気がしてましたが、一発で革新なんて考えない方が良いですね。
もちろん専門的な統計学や経験等のパターン等はあると思いますが。。。
現場・システム・経営等々の横断的なチームで分担ではなく協力、運用してブラッシュアップしていくのが大事そうです。
データサイエンティストがいれば最強ですが今は引く手数多でしょう。。。

そうそう。データをグリグリしているとデータ間のインスピレーションが増すそうです。
なんとなくこのデータを付け合わせればこうなる気がするみたいな。
大抵そういう時は良い結果につながる事のが多いそうです。
なんでしょうか。この修行の成果的な。何気にこういうの大好きですが、私の場合は「そのうち考えるのをやめた」状態になりそうです。

私が勝手に汲み取った感じでは、ビックデータは流れを見るもので、
データ間のインスピレーションの欠片を見つけたら、イマジネーションを膨らませてロジカルに落とし込む。
アジャイル的にガンガン回すべし。
AWSで初期投資少ない。
ビビるな始めろ。
之極意也。
間違ってたらすいません(/ω\)

運用の大事なポイントとしては、大量のデータが集まってくるので、
データ品質を保つためにDWHへの集約と徹底が必要になりそうです。時にはETLも視野に入れると良い。
また、ビッグデータとはいえ不必要なデータと判断したら捨てるのも大事との事。断捨離やー。
そして大量のデータを捌き始めると機械学習が顔を出してくる様です。むぅ。。。
Deep Learningで自動でタグを付けるかっちょいいなー。

技術的な注目としてAmazon.com(小売)のRedshiftの紹介がありました。
大量データをRedshiftで捌くベストプラクティス等がありましたが、
記載して良いのかわからないのでこちらは割愛させて頂きます。

他にも分析手法とか事例とか強いツールの紹介とかAMLについてとか素晴らしい講演がありましたです。なんとなく全体像が見えたのでちょっと色々実験してみようと思います。
それにしてもクラウドやIoTの躍進により、色々な業界が近しくなった事を実感した1日でした。

Pocket

TOKYU HANDS meets Docker

Pocket

こんにちは、井上です。

先週末、東急ハンズのネットショッピングサイト、ハンズネットのWEBアプリケーション・サーバーを、ElasticBeanstalk MultiContainer Docker でリプレイスを行いましたのでその紹介をしたいと思います。

TokyuHands-Docker

ハンズネットはシステム構成として、ざっくりとフロントのWEBアプリケーション・サーバーとバックエンドのAPIサーバーにより構成されています。

バックエンドのAPIサーバーについては、2014年の4月頃からBeanstalk/PHPに順次置き換える作業を進めており、DynamoDBとBeanstalkによるオートスケールの効果もありそこそこ負荷に耐えられるようになってきたのですが、それに伴いフロントエンドの部分がスケールしないことがボトルネックになってきていました。

特にTVの放送時などの突発的なアクセス増の際には、手動によるスケールには限界があり、
ヒルナンデスや、マツコの知らない世界などの特集でハンズの商品が紹介されると、サーバーに接続しづらい状況になることが度々ありました。恐るべしマツコ効果。

Beanstalk-Docker

オートスケール化の一番のポイントは、サーバー自体に状態を持たないようにするという部分だと思うのですが、以前よりWEBアプリケーション・サーバーとAPIサーバーが分離されていたため、その部分では大きな障壁なく進める事が出来ました。
一部、特集コンテンツのようなものや、画像、CSSなど、サーバー内で保持しているデータがあったため、まずはそれらをCloudFront経由での配信に切り替え、第2段階としてBeanstalkに乗せる作業を行いました。

今回この作業によりフロントエンドの部分もオートスケールに対応したため、スパイクアクセスで接続しにくくなる状況は改善されるのではと思っています。
Dockerについては、本番環境に投入して間もないことから、運用上どういう問題が発生するかまだ未知数な部分がありますが、何かありましたら、こちらで報告させていただきます。

今のところ、レスポンスタイムも切り替え前と変わらず、安定して稼働しています。

1点困ったのが、ルートドメインとBeanstalkの相性の悪さです。
ハンズネットは、 https://hands.net/ というサブドメインなしのURLで運用しており、今まではRoute53のAliasレコードとしてELBを登録していたのですが、AliasレコードにはBeanstalkで払いだされる xxxxx.elasticbeanstalk.com といったドメインを指定することができません。
なので、せっかくBeanstalkで SWAP URLなどの機能があってもそれを使う事はできず、AliasレコードとしてBeanstalkの生成するELBを指定するという形になってしまっています。

新バージョンへの環境を切り替えを行う際には、Route53でAliasレコードをいじらないといけないですし、Rebuild EnvironmetするとELBが変わってしまうのでうかつに行えません。

何か良い方法などありましたら教えて頂けると嬉しいです。

また、ハンズがなぜサーバー負荷対策を必死こいてやってるかというと、毎年8月末に、ハンズメッセという大バーゲンがあるのも要因のひとつです。
お店も行列が出来るほどの大盛況なのですが、ネットストアも毎年大わらわで、現在、負荷対策真っ盛りです。

ハンズメッセ2015開催

今年は 8月27日〜 (ネットストアは 8月26日 18:00〜) です。お得な商品を多数販売しますので、ぜひチェックしてみてください!

ではでは。

Pocket