RedshiftとAurora、知らないうちにどんどん進化するAWSの2つのデータサービス：ほぼ月刊AWS（1）（1/2 ページ）
Amazon Web Servicesに関する新たな動きを月単位でまとめる新連載、「ほぼ月刊AWS」。第1回は、エッジとデータ関連サービス、既存システムのクラウド移行に関する新たな動きについてまとめます。
こんにちは、アイティメディア＠IT編集部の三木です。これから「ほぼ月刊AWS」という連載をお届けします。パブリッククラウド、特にAmazon Web Services（AWS）に関しては情報があふれています。でも、次々に新しい発表が行われ、全体的な把握が難しくなってしまうことがよくあります。また、いったん発表された製品が急速に進化し、綿密にフォローしていないと取り残されてしまうことがあります。そこでこの連載では、AWSに関するさまざまな発表の「文脈」をお伝えしようと考えています。
第1回は、アマゾンウェブサービスジャパン（以下、AWSジャパン）が2020年7月20日に行った、2020年4〜7月におけるAWSサービスの最新情報説明から、主にエッジとデータ関連サービス、既存システムのクラウド移行に関する新たな動きについてまとめます。
「エッジ」に向けた発表が目立つAWS、でも結局「エッジ」とは？
最近のAWSで分かりやすいのは、「エッジ」に向けたハードウェアの発表です。2020年6月に発表の「AWS Snowcone」は8TBのストレージを備え、衝撃耐性に優れたボックス型のコンピュータです。以前からある「AWS Snowball」の小型版ともいえ、大容量のデータをネットワーク経由でアップロードする代わりにこれに収めて送付できます。
Snowconeはコンピュータですので、AWSの演算サービスをオフィスや工場、車両などに「出張」させる形で、処理を実行できます。AWSはこのような「出張」を、さまざまな形で進めています。企業のデータセンター向けには「AWS Outposts」、通信事業者のエッジコンピューティング向けには「AWS Wavelength」、そして特定地域における低遅延コンピューティングニーズに対しては「AWS Local Zone」を発表しています。
パブリッククラウド事業者やその他のITインフラ事業者は最近、「IoT（Internet of Things）」や「エッジ」への取り組みを強化してきました。パブリッククラウド事業者にとって、こうした対応は非常に重要な意味を持っています。
パブリッククラウドの原点は、分散してきた多様な組織や用途のITニーズを、巨大なデータセンター群に集約することで、処理能力とコストという点での効率化を図ることにあります。では、自社のデータセンターでは対応できない、あるいは対応しきれないニーズに、クラウド事業者はそれぞれどうアプローチするのか。世界中に無数の「ミニリージョン」を構築していくのか。その場合、採算性をどう設計するのか。また、ミニリージョンでも対応しきれないニーズはどうするのか。
筆者も過去5年余りにわたり、こうした点に大きな関心を抱いてきました。AWSについても、年次イベント「AWS re:Invent」を取材する度に、「IoT」「エッジ」「分散クラウド」などの言葉を使って、AWSの担当者に、「IoT戦略」「エッジ戦略」「分散クラウド戦略」を聞いてきました。しかし、その答えはいつも、大まかにいえばAWSお決まりのセリフである「顧客ニーズ次第」というものでした。
こちらとしては「顧客ニーズ次第」を聞きたいわけではなく、多様性の高い顧客ニーズにどこまできめ細かく、また、どのようなやり方で対応するのかに関心があるため、いつも歯がゆい思いがします。
そうこうしている間に、AWSは下の図に見られるように、IoT、エッジ、分散クラウドで、さまざまな選択肢を提供するようになりました。
この図には含まれていませんが、2020年5月にAWSが発表した「AWS Elemental Link」も、用途特化型のエッジソリューションの一つと表現できます。これは3G-SDIやHDMI経由で取り込んだビデオや音声をライブ動画サービスにつなげる、ビデオエンコーダーボックスです。
AWSが今でも、「場所としてのクラウド」を追求していることには変わりありません。顧客のあらゆるアプリケーションやデータを、何とか自社のリージョンに引き寄せたいからこそ、「VMware Cloud on AWS」のようなこともやっています。
一方でIoTやエッジ、特に5Gで期待されるアプリケーションの中には、一般的なリージョンの粒度ではカバーできないレベルの低遅延やローカル処理を求めるニーズが厳然として存在しています。AWSはこれに対し、「AWS Local Zones」「AWS Wavelength」「AWS Outposts」のように、汎用コンピュータを使ったハードウェア込みの「子リージョン」的なソリューションや、「AWS Snowball」「AWS Snowcone」「AWS Elemental Link」のような、（程度の違いはあるにせよ）用途を絞ったターンキーのボックス、あるいはアプライアンスを次々に投入してきました。
AWSは可能な限りハードウェア込みのターンキー的な仕組みを展開しています。これは、現在のところ「ソフトウェアファースト」を貫いているように見えるGoogle Cloudと対照的です。また、AWSはエッジをクラウドに接続する取り組みについて、「continuum（コンティニュアム：連続体）」だと表現しています。これは日本語にするのが難しい言葉です。
要するにIoT／エッジ／5Gなどでは、個々のニーズを明確に分類できず、グラデーションのようになっています。このため、求められる粒度や低遅延性、便利さなどに関するニーズに応じ、通常のAWSリージョンから、Local Zones、Wavelength、AWS Outposts、Snowball、Snowcone、Elemental Linkなどを臨機応変に適用していくということでしょう。その過程では、小規模企業や小規模拠点のニーズをカバーする小型アプライアンスの登場も、今後期待できるのかもしれません。
Redshiftでは処理とストレージの分離が進めながら、独自の「ひねり」も
AWSのデータウェアハウスサービス「Amazon Redshift」では、2019年12月のre:Inventで2つの大きな発表がありました。「RA3ノード」と「AQUA（Advanced Query Accelerator）」です。AQUAは「2020年中ごろに登場」とされていましたので、いつ発表がなされてもおかしくありません。RA3に関しては2020年4月、より小規模なデータ分析ニーズに対応した第2の選択肢が提供開始となりました。
2019年12月の「AWS re:Invent 2019」で登場したRA3ノードでは、「処理とストレージの分離」が図られています。
Redshiftは、「シェアドナッシング」と言われる、演算処理とストレージを1対1で結合した設計で提供されてきました。この設計におけるパフォーマンスとデータ容量の限界に対応しながら、コスト効率を高める取り組みが、RA3ノードです。
RA3ノードは大容量のSSDを搭載し、これをキャッシュとして使います。そして、よりコールドなデータの管理にはAmazon S3を活用します。これにより、単一のノードでも大容量のデータを扱えると共に、複数のノードを並列的に利用することで、処理性能を上げられるようにしています。処理能力とストレージ容量を、個別に拡張できるわけです。
2019年12月に登場したのは、48の仮想CPU、384GBのメモリを備え、ノード当たり最大 64TBのストレージに対応する「RA3.16xlargeノード」でした。これで磁気ディスクを用いた大ストレージ容量の「DS2.8xlargeノード」によるクラスタを2分の1の数に集約すれば、コストを同等に抑えながら、パフォーマンスとストレージ容量を2倍に高められると説明していました。
ただし、データ量が10TB以下の場合、RA3.16xlargeではメリットが出ないため、「RA3.4xlargeノード」を待つべきと説明していました。
2020年4月に東京を含むリージョンで一般提供が始まったRA3.4xlargeは、CPUとメモリをRA3.16xlargeの4分の1に抑え、利用料金も4分の1になっています。これを使うことで、データが5〜10TBの場合でもメリットが出せるようになったとしています。
Copyright © ITmedia, Inc. All Rights Reserved.