構築中。

名古屋のITインフラお守り係です。ITイベントへの参加記録などを残していきます。

本の紹介/Amazon Web Services負荷試験入門

もうかなり前に発売された本なので、いまさらですが…

gihyo.jp

発売とほぼ同時に入手したものの、通勤時間を中心に読んでいたら、読み終えるまでに意外と時間が掛かってしまいました。

これ以外の負荷試験本を読んだことがないので他との比較はできないのですが、狭い意味での「負荷試験」の正しいやり方を理解する上ではとても良い本だと思います。

たまたま後で知ったのですが、職場の後輩もほぼ同じタイミングで購入して読み始めていて、「わかりやすいて良い」と言っていました。

 

ただ、私としては、「限界を把握した上で様々な対処を考える」「意図通りスケールすることを確認する」という目的ではなく、「実環境で問題が出ない構成であることを確認する」目的では、少し足りていない部分があると感じています。

というのも、この本では、しきりに「攻撃サーバは負荷試験対象のシステムのすぐそばに配置する」ことを強調しており、それはこの本の文脈の上では正しいのですが、「実環境で問題が出ない」ことの確認にはかえって逆効果になることもあるからです。

クライアントは、接続してくる場所や回線の種類によってレイテンシがかなり変わります。モバイルであれば特にレイテンシは大きくなります。そこで問題になるのは、大きく言うと2点。

 

・回線まで含めるとシステムの性能が十分出ない→ユーザにとって「もっさり」した「使いにくい」システムになっている可能性がある

・クライアントからの通信のレイテンシの変化により、システムの個々の要素が必要とするリソースの量や配分が変化する可能性がある

 

前者は、割とイメージしやすいと思いますが、「アプリケーションを含むシステム内部の性能は十分だったが、外部回線(インターネット)経由で利用したらレイテンシが大きくなり過ぎて動作が「カクカク」ぎこちなくなってしまうようなケースです。

「同時利用ユーザが少ないうちは問題がなかったが、増えてきたらそのような現象が発生するようになってしまった」という事象が考えられますが、これについては「回線分のレイテンシを上乗せして、性能が十分か」をある程度シミュレーションできますしそれを思いつくことも容易なので、そんなに問題ではないと思います。

※「レイテンシが大きくなって実質的な帯域が制限されてしまい、結果としてユーザが使いづらくなる」ケースはもう少し注意が必要です(机上計算でシミュレーションは可能ですが)。TCPのウィンドウ制御と同じような、レイテンシが帯域に制限を与えにくい仕組みをより上位のレイヤに実装しないといけなくなる(あるいはTCPのウィンドウ制御を生かす実装にしないといけない)可能性がありますので。

 

問題は後者です。「システムの個々の要素に最大の負荷を与えて限界を確認しておけば大丈夫」だと思いがちですが、例えばロードバランサ/リバースプロキシのクライアント側コネクション/セッションの同時利用数は、接続クライアントの数と接続間隔が同じなら(rpsが同じなら)、クライアントとの通信が遅いほど多くなります。

システムの構成、例えば使用するミドルウェアの種類や設定、あるいはアプリケーションの処理方法によっては、より「後方」の部分(DB、ストレージ側)の必要コネクション数に影響を与える可能性があります。

ELB(ALB・CLB)を使えばコネクション数など気にしなくても良さそうに思えますが、同時コネクション数が変わればELBがスケールするタイミングに影響を与えますし(暖機申請の要否などに影響)、適切なタイムアウト時間設定値も変わってくる可能性があります(ELBを調整したら、接続先のWebサーバのコネクション数やタイムアウト時間、場合によってはOSで設定する利用可能ポート番号範囲やタイムアウト時間などの調整まで必要になることもあります)。

クラウドだからといってこの点を軽く見ると、痛い目にあいます(実際、過去にあいました!)。

※「クラウド環境なので意図通りスケールすればそこは問題にならない」と考えられているのかもしれませんが。実際は、そんなにお行儀の良いアプリが走っているとは限らないので、コトはそれほど簡単ではありませんし、仮に障害なくスケールしたとしても、「意図通り」のスケールではないはずです(リソースの無駄遣いになったり、とか)。

 

というわけで、この点について明確に触れていない点がとても気になりました(Chapter 5の外部システム連携の話で、せっかく近いところに触れているのに…)。

特に、(経験の浅い)後輩が「わかりやすい」と言って読んでいたので、そのような前提知識を持たない人がこの本だけ読んで「正しいやり方」を「完全に把握した気」になって痛い目にあわなければいいのですが。

とりわけ、レガシーシステムを「とりあえず一旦EC2中心の構成でAWSに持ってくる」ケースなどにハマりそうです…。

 

…と、なんだかけなしているように受け取られそうですが、この点を除けば(あともう1つ、負荷試験なのに「CPU使用率」について深く突っ込んでない点…といってもあまり深く突っ込むとページ数が増える上にかえって読者が混乱しそうですし、クラウドだからスケールする前提で「こまけぇこたぁいいんだよ!」かもしれませんが)、非常に参考になる本だと思います。

 

参考情報:

yakst.com

JAWS-UG名古屋 re:Inventに行ったつもりのLT大会&忘年会(12/20)

JAWS-UGで何かやってないかな?と思って色々ググっていたらたまたま見つけたので、

jawsug-nagoya.doorkeeper.jp #jawsug

に参加しました。

先日、

hmatsu47.hatenablog.com

へ参加したのでその復習を兼ねての参加でしたが、LTされた皆さんの発表内容がかなりしっかりしたものだったので、ちょうど良い復習になりました(個々の内容については省略。Twitterで #jawsug を検索すると、他地域で同時開催のLTとともに名古屋のLTもちょっとだけ雰囲気を味わうことができます)。

 

明日の夜も予定があるので二次会には参加できず、交流を図ることはできませんでしたが、

alexaday2018.jaws-ug.jp

(参加申込済み)や、

jawsdays2018.jaws-ug.jp

には参加する予定なので、そこで頑張ることにします(まあ、LTのほうを真剣に聞いてしまいそうですが)。

AWS re:Invent 2017 ダイジェスト 大阪(12/15)

今回は業務で後輩を連れて(ほかにグループ内の情シス部門の担当者も伴って)行ってきました。

AWS re:Invent 2017 ダイジェスト 大阪 | AWS

 

おそらくメールアドレスを書き間違えたために受講票が届かず、また気づいたのが前日夜で担当営業さんにも連絡が付かず、というわけでそのまま現地に突入しましたが、あっさり入れました。

※行ったときには何人か会場を待っている人がいましたが、「受講票が届いていない」旨誘導係の人に伝えている間に気づいたら入場列が後ろに形成されて何故か列の先頭になってしまい、受講票メールは届いたものの印刷を忘れた後輩とともに「面倒な客」が先頭から2人連続する、という迷惑な展開になってしまいました。

 

内容は書き始めると長くなるので、気になった点だけ記します。

 

 

AWS re:Invent キーノートサマリー(清水 崇之さん)

今年のre:Inventでは動画・映像関連が盛り上がっていた、という噂通り、追加サービスの話はAWS Media Services群から始まり、その次にAR・VR・3D向けのAmazon Sumerian、去年まで盛り上がっていた音声は、大きなくくりでは3番目に紹介されていたのが印象的でした(Alexa for Business)。

日本ではようやく本格的にサービスが始まるところですが、本国ではもう落ち着いた、という話も聞きますし。

それに続くのはIoT関連、ここはガチ向けのほかに1-clickでIoT用Lambda、というライトユーザ向けのサービス強化を進めている、ということです(これはIoTに限らずAWS全サービス共通の傾向)。

その次が分析用データをためるデータレイクの話で、5番目にようやく機械学習(ML)の話が出てきましたが、これは「MLに力を入れていない」ということではなく、おそらく後で独立したセッションで解説を行うことが理由でしょう(実際、フレームワーク層からアプリケーション層まで満遍なくサービスを追加・強化しています。同じく、独立したセッションで解説する、プラットフォームやDBの話も後のほうに続きます)。

次が開発者向け(AWS AppSyncやMQ、Cloud9など)、続いてEC2、k8s、Fargate、大阪ローカルリージョン開設(2018年中)の話、NW関連(PrivateLinkなど)、DB関連(DynamoDB、Aurora、Neptuneなど)と来て、最後がGuardDutyなどのセキュリティの話でした。

最後に、「来年のre:Inventは11/26~30に開催するから、是非来てね!」という話があってこのセッションは終了しました。

 

プラットフォーム最新アップデート(荒木 靖宏さん)

プラットフォームについては、以下のような点について触れられていました(気になった点のみ抜粋)。

 

  • EC2・ECS(Fargate含む)のSLA99.99%に上がった
  • AZ内でEC2を物理的に分散させるSpread Placement Group
  • kubernetesユーザの6割以上がAWSを使っている
  • Direct Connect Gateway(Direct Connect(DX)のHub)迂回経路の設定はあえてユーザに任せる
  • インターリージョンVPNピアリングでは自動暗号化可能
  • PrivateLinkではインターネットに出ずにVPC間およびDX経由でNLB背後のAPIリクエストが可能に(SaaSアクセスに使える・マーケットプレイスでの公開も)
  • AWS WAFでパートナーから提供されたマネージドルールが利用可能に
  • SSO基盤の提供

 

※C5・M5などの新インスタンスやBear Metal、T2 Unlimited、Fargate、EKS、Time Sync Service(高精度NTP)、GuardDuty、System Manager、S3 Selectなどの話は事前チェック済みの範囲の話だったので省略。

 

データベース最新アップデート(星野 豊さん)

こちらも気になった点のみ抜粋します。

 

  • Neptune(マネージドグラフDB)では億単位のリレーションを保管した状態で msオーダーのレイテンシ、3AZ・6コピーはAuroraと同じ
  • Aurora PostgreSQL互換では本家との比較で速度は2x程度だがスループットが安定、リカバリはWAL不要なので非常に高速(場合によって85x Faster)
  • Performance Insight DBプレビュー中、ロックの内訳がわかる
  • Aurora Multi-Masterプレビュー中、まずはシングルリージョンから、Hierarchical conflict resolution(分散合意形成システム)
  • Aurora Serverlessプレビュー中、秒単位のレイテンシが発生しうるため、通常のAuroraに適したワークロードには向かない、DBノードはコンテナではなくあらかじめ起動しておいたEC2インスタンスをストレージノードのデータに「くっつけたり引きはがしたりする」ことでスケールする(ユーザはプロキシで振り分けられた「自分のデータ」にくっつけられたDBノードに、プロキシ経由でアクセス)
  • Aurora MySQL互換(1.16)のラボモード機能(Batched scans、Hash Join→私も実験済み)※パラレルクエリはComing soon
  • Aurora Auto Scalingの現行バージョンではスケールアウトで追加されたリードレプリカのバッファキャッシュ(バッファプール)が暖機されないので注意(この点については私も実験済み
  • AuroraのDatabase Cloning(瞬時にコピー作成)、Backtrack(すばやくPITR)
  • RDS for MySQLとAuroraのIAM Integration
  • RDSデータ容量上限UP(→16TB)
  • Dynamo DB Global TablesではDynamoDB Streamsを裏で利用、1s程度のレイテンシ(確認用メトリクスあり)、新規DBのみ適用
  • Dynamo DBのバックアップ/リストア対応、今後PITR対応予定(瞬時にはリストアできない)
  • ElastiCacheでシャード数・容量上限UP、for Redisではオンラインリシャーディング可能に

 

※多いので後は省略。

 

AI & Machine Learning 最新アップデート(桶谷 拓也さん)

同じく気になった点のみ。

一気に増えたせいもあり、まだ東京リージョン・日本語への対応行われていないサービスが多いです。

 

  • Rekognition Video 動画対応(ライブOK)、高速化、多人数対応、有名人認識、不適切コンテンツ認識、タイムスタンプ付与(先頭からのオフセット把握可能→検索Indexなどに便利)
  • Comprehend 自然言語理解(入力テキスト分析)
  • Translate(プレビュー)Deep Learningに基づいた多言語間翻訳サービス
  • Transcribe(プレビュー)Speech-to-Textサービス、リアルタイムにも対応、電話音声対応、カスタム語彙対応
  • Kinesis Video Streams 大量のカメラからアップロードされる動画ストリームに対応可能
  • SageMaker end-to-endのフルマネージドMLサービス
  • DeepLens 深層学習モデルで推論可能なビデオカメラデバイス
  • 色々なレイヤのサービスが提供されているので、利用するにはレイヤの見極めが必要

 

セッション間に質問スペースでの質問タイムが設けられていましたが、時間が短くトイレタイム確保のためあえて行かないことにして、全セッション終了後の質問タイムに突撃しました。

その戦略(?)が成功し、最後、清水さんと星野さんを立て続けに捕まえて「独り占め」(後輩と2人で、ですが)状態でお話しすることができたのが大きな収穫でした(ビジネス向けのITイベントは参加者が帰るのが早いです…大阪も名古屋も)。

1つ質問をド忘れして聞きそびれてしまったのが残念でしたが、聞き忘れたのはAuroraの仕組みについての個人的な興味の話なので、業務上はどうでも良いことでした。