Amazon Web Services ブログ

Tag: General

AWS ホットスタートアップ – 2017年7月

今月も引き続き、ホットなスタートアップ企業を紹介していきます。日々、スタートアップ企業は革新的であっと言わせるようなビジネス、アプリケーション、製品を世界中で製作しています。AWS では毎月、AWS を使用して何か優れたことをしているスタートアップ企業を紹介しています。 7 月は学習に関する企業を集めました。次の企業は様々な方法で知識や技術を拡張するためのツールやリソースへのアクセス提供に重点を置いています。 今月のスタートアップ企業をご紹介します。 CodeHS – 中高生を対象に、使って楽しくアクセスしやすいコンピュータサイエンスのカリキュラムを提供しています。 Insight – データサイエンス分野の技術的な才能を伸ばすための集中的なフェローシップを提供しています。 iTranslate – 90 か国語以上の言語で読み取り、書き取り、会話ができるサービスを世界中で提供しています。 CodeHS (カリフォルニア州サンフランシスコ) 2012 年、スタンフォード大学の学生だった Zach Galant 氏と Jeremy Keeshin 氏は、コンピュータサイエンスを専攻していました。そして初級レベルのクラスの教育助手をしていた時に、ある傾向に気が付いたのです。多くの学生が、もっと小さい頃からコンピュータサイエンスに関わっていたかったということです。大学 4 年の時に Zach と Jeremy は中高生が楽しく、アクセスしやすいコンピュータサイエンス教育を提供するチャンスを作るために CodeHS を立ち上げました。CodeHS はウェブベースのカリキュラムで、指導者のリソース、レッスンプラン、専門的能力の開発チャンスで成り立っています。カリキュラムは時間節約を意図して作られた指導者用のツールを伴い、レッスンプランや採点、学習者のコードの評価、クラスルームの管理ができます。 CodeHS は、すべての生徒が将来に向けて意義ある影響力を培えるように取り組んでいます。また、コードを学ぶことは読解力と共に現代の新たな基礎的能力であると考え、そうした技術を身に着けることで生徒がより深く個人の興味や学習を拡大していくことができると見ています。CodeHS が設立された 2012 年には、コンピュータサイエンスのコースを提供している米国内の高等学校は 10% ほどでした。Zach と Jeremy は学校や学区が簡単に取り組めるようにするためのソリューションを提供することで、その現状を変えることに努めてきました。CodeHS により、何千人もの指導者がトレーニングを受け、何百何千人という世界中の生徒達に指導できるようになりました。CodeHS を使用するにあたり必要なのはインターネットとウェブブラウザだけです。生徒はオンラインでコードを書き、実行することができます。指導者は生徒が何に取り組んでいるか、そして進み具合などをすぐにチェックすることができます。 Amazon EC2、Amazon RDS、Amazon ElastiCache、Amazon CloudFront、Amazon S3 は CodeHS […]

Read More

3つのトレーニングコースを新設(※日本では2コース開催)

エキスパートから学ぶことができる AWS トレーニングでは、実践的なスキルや AWS クラウドの活用方法について知識を増やすことができます。本日より、トレーニングブートキャンプでもっとも人気のある 3 つ (AWS re:Invent や AWS グローバルサミット でお馴染みです) のコースが、AWS によるインストラクター主導トレーニングの一部として含まれるようになりました。 サーバーレスデータレイクの構築– AWS サービスでのサーバーレスデータレイクソリューションの設計、構築、操作の方法を説明します。 クラウドへの転換を成功させる秘訣 – ワークロードをクラウドに移行させる際に必要となる適切な戦略、スタッフ、移行プラン、財務管理方法について説明します。技術的に高度な専門知識は必要ありません。 AWS でコンテナ対応マイクロサービスを実行 – Amazon EC2 Container Service (ECS) を使用してコンテナ対応アプリケーションの管理とスケーリングする方法を説明します。 こうした 1 日コースはエキスパートトレーナーから専門的なトピックの詳細を学びたい方を対象にしています。 コースカタログ一覧で詳細を見たり、お近くで開催される講座を AWS トレーニングと認定ポータルで検索することができます。チーム専用にプライベートのオンサイトトレーニングセッションをご希望の場合は、こちらからお問い合わせください。 — Jeff; 日本ではお客様向けの新規2コースを9月から開始: AWS Summit Tokyo 2017 のBoot Campメニューで選考提供した以下の2コースを、この秋より定期コースとしてリリースします。いずれも1日コースです。お申込みいただけるようになりましたら、改めてご案内致します。 ·         Running Container-Enabled Microservices on AWS: 9/19(火)@西新宿会場 ·         Building a […]

Read More

Amazon AppStream 2.0 のGPU強化によるストリーミングインスタンス

re:Invent 2016 でリリースした Amazon AppStream 2.0 についてお知らせします。このアプリケーションストリーミングサービスは、デスクトップブラウザに Windows アプリケーションを配信することができます。 フルマネージド型の AppStream 2.0 は、多目的、コンピュート最適化、メモリ最適化のストリーミングインスタンスでアプリケーションを実行することにより、一貫性のあるスケーラブルなパフォーマンスを提供し、安全で忠実度の高いストリーミングプロトコルの NICE DCV を介して配信します。エンタープライズおよび公的機関のお客様は、レガシーアプリケーションストリーミング環境の代わりにオンプレミスでインストール済みの AppStream 2.0 をすでにご利用されています。こうしたお客様は AppStream 2.0 を使用して、商用アプリケーションおよびビジネスアプリケーションをデスクトップ ブラウザに配信しています。ISV をご利用されているお客様はコードを変更せずに、AppStream 2.0 を使用してアプリケーションをそのままクラウドに移動しています。こうしたお客様はデモ、ワークショップ、企業の SaaS プランなどに注目しています。 高評価を頂いている AppStream 2.0 には新しい機能が迅速に追加されています (AWS の平均に比べても速い方です)。今年に入ってからすでに image builder、SAML 2.0 のフェデレーティッドアクセス、CloudWatch モニタリング、Fleet Auto Scaling、シンプルなネットワークセットアップ、ユーザーファイル用の永続的ストレージ (Amazon S3 によりバックアップ)、VPC セキュリティグループのサポート、ユーザー向けのウェブポータルを含む組み込みのユーザー管理が追加されています。 新しい GPU によるストリーミングのインスタンス 専用のデザイン、エンジニアリング、HPC、メディアアプリケーションをユーザーに提供するために AppStream 2.0 を使用したいというリクエストを数多く頂きました。こうしたアプリケーションは、通常グラフィックスを集中的に使用し GPU (グラフィックスプロセッシングユニット) と組み合わせた高額で高性能の […]

Read More

Hightail — クラウド上での創造的なコラボレーションを支援

Hightail (旧社名: YouSendIt) は、世界各地の 5,000 万人以上の専門家が優れたコンテンツをユーザーに提供できるよう支援することで、創造的な作業の確認、改善、承認方法を合理化しています。Hightail は、ファイル共有会社として 2004 年に設立されて以来、付加価値のある創造的なコラボレーションサービスの提供へと戦略的方向を転換し、著名な顧客を数多く獲得しています。 本日のゲスト投稿では、Hightail の技術担当上級副社長である Shiva Paranandi 氏が、同社が実施したオンプレミスからクラウドへのペタバイト単位のデータ移行について語ります。クラウドベンダーの評価プロセスと、すべてを AWS に移行した理由が述べられています。 Hightail はユーザーが大きなファイルを簡単に共有して保存できる方法を提供するために設立されましたが、それ以降、創造的なコラボレーションツールへと進化してきました。当社は、ユーザーがデジタル資産を管理、共有するだけの場所ではなく、創造的なチームを作り、顧客とつながり、創造的なワークフローを開発して、最初から最後までプロジェクトを管理できる場所になりました。現在では、Lionsgate や Jimmy Kimmel Live! といった有名ブランドのコラボレーションサービスの原動力となっています。当社は、国内外の顧客が増える中で、製品開発とユーザーへのサービスに対して社内的により傾注する必要がありました。独自のデータセンターの運営には、予定していたよりも多くの時間、費用、人材が必要になることがわかりました。 より迅速に反復して顧客のニーズを満たし、市場までの時間を大幅に改善する手法が必要でした。データセンターのコストを削減し、世界各地の特定のリージョンで迅速にスケールアップする柔軟性が必要だったのです。新しい場所でのデータセンターの設営には長い時間がかかり、当社が達成できる成長ペースの妨げとなっていました。さらに、使用することもないストレージキャパシティーを所有することになる、ニーズに先回りした購入にはうんざりしていました。頻繁に使用しないデータを非アクティブなストレージに保持する一方で、顧客のリクエストに応じてそのデータを迅速に取り出せることでコストを削減する、階層型で非常にスケーラブルなストレージソリューションが必要でした。当社の主な推進力は俊敏性と革新であり、クラウドはそれらを強力に可能にしてくれます。それを踏まえて、ストレージとコンピューティングインフラストラクチャの管理にリソースを投入するのではなく、ビジネスを差別化する構想に時間とコストを費やすことができる、クラウドファーストのポリシーを採用することに決定しました。 AWS とクラウド競合他社の比較 移行の開始にあたって、まず AWS、Google、IBM、Microsoft を含むさまざまなクラウドベンダーの評価を行いました。当社にとっては明らかに AWS が抜きん出た選択肢でした。ある時点では、ニーズを満たすために複数のクラウドプロバイダーからのサービスを組み合わせることを検討しましたが、最適なルートは AWS を単独で使用することであると判断しました。トレーニング、同期、サポート、システムの可用性、それに他の移行や管理の要素を考慮すると、複数のクラウドを使用する手法は実用的ではありませんでした。最善のコスト削減と、ほかに例を見ないパートナーソリューションのエコシステムにより、他のベンダーは必要なく、すべてを AWS に移行することを選択しました。 AWS に移行することで、ギガバイトあたりの最低料金、リッチなエコシステムへのアクセス、社内の迅速な人材開発、SOC II コンプライアンスの維持が可能になりました。エコシステムは特に当社にとって重要で、非常に多くのパートナーを持つ AWS は競合他社とは一線を画していました。実際に、イメージのプレビュー、ビデオのエンコード、プレゼンテーションの提供などのサービスについて当社が依存しているすべてのベンダーは既にこのネットワークに参加しているため、既存の投資や専門知識を簡単に利用することができました。別のプロバイダーを選択していれば、既に正しく稼働しているプラットフォームからの移行が必要になりますが、これは当社にとって望ましい結果ではありませんでした。また、AWS のテクノロジーについて社内で開発できる人材の数も驚くべきものでした。AWS の使用に関する内部チームのトレーニングは、AWS カンファランス、トレーニング教材、サポートなどの利用可能なツールを使用した簡単なプロセスです。 ペタバイト単位のデータの移行 AWS を選択したことで、作業が簡単になりました。多くの場合、社内で使用していたよりも優れた機能が提供されました。オンプレミスストレージから AWS に数ペタバイトのデータを簡単に移行できました。AWS の Direct Connect により高速に処理を進めることができたため、3 か月ほどですべてのデータをプッシュできました。それによるユーザーへの影響はありませんでした。AWS Key […]

Read More

AWS のディープラーニング

私のようなタイプの人であれば、人工知能 (AI) や機械学習 (ML)、ディープラーニングは実に興味深く胸を躍らせるトピックではないかと思います。AI、ML、ディープラーニングが今まで以上に幅広く利用されるようになるに連れ、Dr. Issac Asimov 氏がサイエンスフィクションで描いた「スター・ウォーズ」に出てくるようなロボット工学そして医学の進歩、さらには「スタートレック」のキャプテンカークやそのクルーに「誰も行ったことのない場所へ、勇敢に突き進もう (to boldly go where no man has gone before)」と言わせたテクノロジーが実際に可能になるのではないかと思わずにいられません。   前述のトピックに興味がある人にとって、画像や動画を複数のカテゴリに区別する畳み込みニューラルネットワーク (Convolutional Neural Networks) や、音声認識、自然言語によるインターフェース、推奨エンジンなど、ディープラーニングにより可能となる AI や ML のソリューションには馴染みが深いのではないかと思います。けれども、データサイエンティスト、機械学習の利用者、リサーチサイエンティスト、ディープラーニングに興味を持つ熱心なユーザー達がこうしたテクノロジーに携わりインフラストラクチャや環境、ツールを設定する作業は必ずしも簡単ではありません。多くの開発者はディープラーニング技術を使用して、ディープラーニングをトレーニングモデルそしてソリューション開発に早く繋げていきたいと考えています。こうした理由から、経験豊富なデータサイエンティストであれ、今から始めたいと思っている興味津々の開発者まで、速くディープラーニングのソリューションを構築したいと思っている方々に向けて、いくつかのリソースをご提供したいと思います。 ディープラーニングのリソース Apache MXNet は Amazon が選んだディープラーニングのフレームワークです。Apache MXNet フレームワークと NVIDIA GPU コンピューティングを組み合わせれば、スケーラブルなディープラーニングプロジェクトとソリューションを簡単に AWS クラウドで開始できます。MxNet のディープラーニングの旅を始める方々を対象に、様々なセルフサービス形式のチュートリアルやデータセットが今すぐ利用できるようになっています。 AWS ディープラーニング AMI の起動: このガイドでは、Ubuntu で AWS ディープラーニング AMI を起動する手順を説明しています。 MXNet – コンピュータビジョンのアプリケーションを作成: この実践的なチュートリアルは構築済みのノートブックを使用してニューラルネットワークの利用でコンピュータビジョンを構築し、手書きの数字を識別する方法を説明します。 AWS […]

Read More

8 月の AWS Black Belt オンラインセミナーのご案内

【注意】セミナーの実施日程について更新がありました.最新の実施日程は,こちらをご覧ください. こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー8月の配信についてご案内させて頂きます。8月は開発者の方々に役立つ内容を多めに放送する予定です。ソリューションカットでは、デプロイをテーマにしたものと,Redshift のテーブル設計についてのものをお送りします。また今年に入って大きなアップデートがあった DynamoDB についてもお送りします。   8月の開催予定   サービスカット 8/2(水) 18:00-19:00 AWS X-ray 8/9(水) 18:00-19:00 Amazon DynamoDB 8/23(水) 18:00-19:00 AWS MobileHub 8/30(水) 18:00-19:00 AWS Key Management Service (KMS) ソリューションカット 8/22(火) 12:00-13:00 Deployment on AWS 8/29(火) 12:00-13:00 Amazon Redshift テーブル設計詳細ガイド お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカー、スタッフ 一同みなさまのご参加をお待ちしております。

Read More

AWS SDK for Java 2.0 開発者向けプレビューを公開

AWS 開発者用ツールのチームは AWS SDK for Java のリリースに向けて熱心に取り組んできました。そして本日、バージョン 2.0 の開発者用プレビューを公開するに至りました。このバージョンは過去にリリースした 1.11.x codebase を大きく書き換えたものです。整合性、イミュータビリティ、使い勝手の良さに視点を向けて Java 8 の上に構築しました。 新しい SDK には、ノンブロッキングの I/O のサポート、ランタイムで使用したい HTTP 実装を選択できるなど、リクエストが多かった機能を含んでいます。新しいノンブロッキング I/O サポートは既存のものに比べより効率的で、サービスクライアントの Async バリアントのスレッドベース実装を取り入れています。ノンブロッキングのリクエストはそれぞれ CompletableFuture オブジェクトを戻します。バージョン 2.0 SDK では、これまでの API にいくつもの変更を追加しています。たとえば、既存のクライアントのコンストラクタと変更可能なメソッドを、クライアントビルダーと変更不可能なクライアントをベースにした非同期モデルと置換します。また、SDK はリージョンをシングルリージョンクラスにするために使用するクラスの異種コレクションを折りたたみ、ストリーミング用 API の新しいセットを提供します。SDK は GitHub でご利用いただけます。GitHub に関する問題をスタートして公開フィードバックを送信したり、いつもの方法でリクエストのプルを送信することができます。 SDK の詳細については AWS 開発者ブログの「AWS SDK for Java 2.0 – 開発者用プレビュー (AWS SDK for Java 2.0 […]

Read More

AWS Summit Tokyo 2017でのAmazon EC2 Container Service (ECS) 関連セッションまとめ

5月末〜6月頭に開催されたAWS Summit Tokyo 2017において、を実際にご利用頂いているお客様からの導入事例セッションとAWSからのTechセッションを合わせると、なんと11ものAmazon ECS関連セッションが行われました。Summit全体で130以上のセッションがありましたので、その中で10%程度がAmazon ECS関連だったということになります。Amazon ECSは、2015年4月にGA(東京リージョン含む)して以来、着実にお客様に導入を頂き、スタートアップからエンタープライズまで、新規システムだけでなくオンプレからの移行でも利用される標準的なサービスとなってきたことの表れかと思います。 この投稿では、それらのセッションを一気に見返せる様に情報を集約してお届けしたいと思います。これらの情報をご覧になって、Amazon ECSの利用をぜひご検討下さいませ。 導入事例トラック ナビタイムサービスにおける、Amazon ECS を活用したシステム移行 ~『乗換NAVITIME』での移行事例 ~ 資料 [リコー] サービス全断はダメ、ゼッタイ。途切れないテレビ会議システムを目指して 〜AWS を最大限活用して可用性を高める秘策〜 資料 動画 クックパッドの機械学習を支える基盤のつくりかた 資料 動画 Amazon ECS と SpotFleet を活用した低コストでスケーラブルなジョブワーカーシステム (※株式会社インティメート・マージャー様事例) 資料 動画 [Intelligence] オンプレから移行するので、Amazon ECS でコンテナ化と Terraform でインフラコード化した話 資料 DAU 100 万人突破! 急成長を支える Shadowverse のインフラ技術 資料 DMM における会員基盤プラットフォームへのAWS導入から活用事例の紹介 資料 動画 [ABEJA] IoT / Bigdata / AI […]

Read More

Amazon Redshift Spectrum 10 のベストプラクティス

Amazon Redshift Spectrum を使うことで、Amazon S3 に置かれたデータに対して Amazon Redshift の SQL クエリを走らせることができます。つまり Redshift Spectrum によって、データウェアハウスのローカルディスク内に保存されたデータ以外に対しても、Redshift の分析を拡張できるようになるのです。S3 の “データレイク” に貯まった大量のデータに対して、面倒で時間のかかる抽出・変換・ロード(ETL)処理を行うことなく、クエリを投げることができます。Redshift Spectrum は洗練されたクエリ最適化を用いて、数千ものノードにまでスケールして高速に処理を行います。 このブログポストでは、Redshift Spectrum の 10 の重要なベストプラクティスについて、いくつかのカテゴリにわけてご紹介します。 このガイドラインは、Redshift をお使いのお客さまとの多くのやりとりや、直接的なプロジェクトに基づいて作られています。 Amazon Redshift vs. Amazon Athena AWS のお客さまは、私たちによく「Amazon Athena と Amazon Redshift Spectrum について、どう使い分けをすればよいのでしょうか?」と尋ねます。 Amazon Athena の利用シーン Athena は S3 に置かれたデータに対して、SQL によるインタラクティブなアドホッククエリを投げるといったユースケースに向いています。Athena はサーバーレスアーキテクチャなので、クエリを投げるためにクラスタを立ち上げる必要はありません。クエリごとにスキャンした S3 のデータ量に基づいて料金が発生します。データを圧縮、パーティショニング、または列指向フォーマットに変換することにより、費用を節約しつつ優れたパフォーマンスを得ることができます。JDBC に対応しているすべての BI ツールや SQL […]

Read More

Amazon Redshiftクエリーモニタリングルールでクエリーワークロードを管理する

データウェアハウスのワークロードは多様性で知られています。これは、季節性や、往々にして高コストになりがちな探索的クエリー、SQL開発者のスキルレベルのばらつきなどによるものです。 Amazon Redshiftワークロード管理機能(WLM)を用いて優先度やリソース使用量を柔軟に管理することで、極めて多様なワークロード環境でも高い性能を得ることが可能となります。WLMによって、短時間で完了するクエリーが長時間実行されるクエリーのせいでキューに滞留するような状況を避けることができます。にも拘わらず、あるクエリーが不釣り合いな量のリソースを独占し、システム内のその他のクエリーを圧迫することが依然として起こり得ます。こうしたクエリーは、一般にrogue queryやrunaway queryと呼ばれます(訳者註:rogueはならず者、面倒を起こすといった意味、runawayは暴走の意で、ここでは一方的にリソースを占有し他のクエリーに影響を及ぼすクエリーを指します) WLMは、メモリー使用量を制限し、タイムアウトを用いてクエリーを別のキューに移動させる機能を持ちますが、ずっと粒度の細かいコントロールができることが望ましいことは論を俟ちません。クエリーモニタリングルールを用いて、リソース使用量のルールを作成し、クエリーのリソース使用量を監視し、それらがルールを犯した時のアクションを決めることが可能になりました。 ワークロード管理における同時並列性とクエリーモニタリングルール Amazon Redshift環境では、単一クラスターに対し最大500まで同時接続することができます。性能指標であるスループットは一般に一時間あたりのクエリー数として表現されますが、MySQLのような行指向データベースであれば、同時接続数を増やすことによってスケールします。Amazon Redshift環境では、ワークロード管理(WLM)によって、同時接続数とは異なる方法でスループットを最大化します。WLMは二つの部分があります。キューと同時並列性です。キューはユーザーグループまたはクエリーグループのレベルでのメモリー割り当てを可能にします。同時並列性(またはメモリースロット)は、この割り当てをさらにどのように分割し、個々のクエリーにメモリーを割り当てるかを制御します。 例えば、同時並列性10の1つのキューがある(メモリー割り当て100%)と仮定しましょう。これは、個々のクエリーは最大10%のメモリーの割り当てを受けることを意味します。もしクエリーの大半が20%メモリーを必要とした場合、これらのクエリーはディスクにスワップアウトし、スループットの劣化をもたらします。しかし、もし同時並列性を5に下げた場合、個々のクエリーは20%のメモリー割り当てを受けることができるため、トータルのスループットは高くなり、SQLクライアントへのレスポンスも全体的に高速になります。高い同時並列性がよりよいパフォーマンスに繋がると考えてしまうことは、行指向のデータベースを列指向に切り替える時に陥りがちな典型的な落とし穴の一つです。 同時並列性について理解したところで、クエリーモニタリングルールについて掘り下げていきましょう。リソース使用量に基づくルールと、それに違反した場合に取るアクションを定義します。当該クエリーによるCPU使用量、クエリー実行時間、スキャンされた行数、返された行数、ネステッドループ(Nested loop)結合など、12の異なるリソース使用量メトリクスを利用できます。 それぞれのルールは最大3つの条件(述語)と、一つのアクションを持ちます。 述語は、メトリック、比較演算子(=、<または>)、値で構成されます。あるルール内の全ての述語がマッチすると、そのルールのアクションがトリガーされます。ルールアクションには、ログ(記録)、ホップ(次のキューへの移動)、アボート(終了)があります。 これにより、はた迷惑なクエリーを、より深刻な問題が出来する前に捕捉することが可能になります。ルールはアクションをトリガーしてキューを解放し、スループットと応答性を改善します。 例えば、短時間実行クエリー専用のキューのために、60秒を超えて実行し続けるクエリーをアボートするルールを作ることができます。設計のよくないクエリーを追跡するために、ネステッドループを含むクエリーを記録する別のルールを作ることもできます。Amazon Redshiftコンソールには、簡単に始められるよういくつかのテンプレートが事前定義されています。 シナリオ クエリーモニタリングルールを使って、単純なロギングからクエリーのアボートまで、幅広いクエリーレベルアクションを行うことができます。また、全てのアクションはSTL_WLM_RULE_ACTIONテーブルに記録されます。 ログ(LOG)アクションは、情報を記録した上でクエリーの監視を継続します。 ホップ(HOP)アクションは、クエリーを中断し、次に合致するキューで再起動します。 もし合致するキューがない場合、当該クエリーはキャンセルされます。 アボート(ABORT)アクションは、ルールに違反したクエリーをアボートさせます。 それでは、以下の三つのシナリオを用いて、クエリーモニタリングルールをどのように使うかを見ていきましょう。 シナリオ1:アドホッククエリーに潜む非効率なクエリーを制御するには? 二つの大きなテーブルを結合するようなクエリーは、何十億、あるいはそれ以上の行を返す可能性があります。十億行を超える行を返すクエリーをアボートさせるルールを設定することで、アドホッククエリーの安全性を担保することができます。このルールは、論理的には以下のようになります。 IF return_row_count > 1B rows then ABORT 以下のスクリーンショットの設定では、十億行を超える行を返すBI_USERグループ内のクエリーはすべてアボートします。 シナリオ 2: 非効率で、CPUインテンシブなクエリーを制御するには? CPUスパイクをもたらすクエリーが、必ずしも問題というわけではありません。しかし、高いCPU使用量と長いクエリー実行時間を併せ持ったクエリーは、実行中の他のクエリーのレイテンシーを悪化させます。例えば、高いCPU使用率を示し続ける非効率なクエリーが長時間実行されている場合、それは誤ったネステッドループ結合のせいかも知れません。 こうしたケースでは、10分間にわたって80%以上のCPU使用率を示しているクエリーをアボートさせるルールを作成することで、クラスターのスループットと応答性を上げることができます。このルールは、論理的には以下のようになります。 IF cpu_usage > 80% AND query_exec_time > 10m then ABORT 以下のスクリーンショットの設定では、10分間にわたってCPU使用率が80%を超えているクエリーはすべてアボートします。 80%以上のCPU使用率を5分以上続けるクエリーを記録し、10分以上続いた場合はアボートするよう、ルールを拡張することもできます。このルールは、論理的には以下のようになります。 IF cpu_usage > […]

Read More