【新時代】データベースの常識を覆すAmazon Aurora Limitless Database

【新時代】データベースの常識を覆すAmazon Aurora Limitless Database 詳細解説

はじめに：データベースの進化と新たな挑戦

デジタル変革の波が世界中のあらゆる産業を飲み込む現代において、データは企業活動の根幹をなす最も重要な資産となりました。このデータを効率的に、かつ安全に管理するための基盤技術がデータベースです。リレーショナルデータベースが登場して以来、数十年にわたり、データの整合性を保証するACID特性（原子性、一貫性、独立性、永続性）を武器に、ミッションクリティカルなシステムの心臓部として君臨してきました。

しかし、インターネットの普及とスマートデバイスの爆発的な増加は、我々が扱うデータの量と速度を、かつてない次元へと押し上げました。テラバイトからペタバイト、さらにはエクサバイト級へと膨れ上がるデータ、そして毎秒数百万に達するトランザクション要求。これらの「ハイパースケール」なワークロードは、従来のモノリシックなデータベースアーキテクチャに深刻な挑戦を突きつけました。

垂直スケーリング（スケールアップ）は、サーバーのCPUやメモリを増強する手法ですが、物理的な限界と指数関数的に増加するコストという二重の壁に直面します。一方、水平スケーリング（スケールアウト）は、複数のサーバーにデータを分散させることで限界を突破しようとするアプローチですが、これは「シャーディング」という新たな複雑性の悪魔を呼び覚ましました。アプリケーションはどのデータがどのサーバー（シャード）にあるかを常に意識する必要があり、シャードをまたがるトランザクションの整合性を保つことは非常に困難です。運用は複雑化し、開発者の生産性は著しく低下します。

このジレンマを解決すべく、クラウド時代は新たなデータベースの形を模索してきました。そして2014年、AWSは「Amazon Aurora」を発表し、クラウドネイティブなリレーショナルデータベースの新たな標準を打ち立てました。コンピュート（処理）とストレージ（保存）を分離するという革新的なアーキテクチャにより、従来のデータベースのパフォーマンスと可用性を凌駕し、多くの開発者に愛されてきました。

しかし、Auroraでさえも、書き込み性能に関しては単一のライターインスタンスの物理的限界という制約から完全に自由ではありませんでした。超大規模な書き込み集中型のワークロードに対しては、依然としてシャーディングという複雑な手術が必要だったのです。

そして2023年、AWS re:Inventにて、その最後の壁をも打ち破る可能性を秘めた、まさにゲームチェンジャーとなる新技術が発表されました。それが「Amazon Aurora Limitless Database」です。

本記事では、このデータベースの常識を覆す可能性を秘めたAmazon Aurora Limitless Databaseが、どのような技術であり、我々のシステム開発とデータ管理にどのような革命をもたらすのか、そのアーキテクチャの核心から具体的なユースケース、導入における考慮事項まで、約5000語にわたり徹底的に解説していきます。これは単なる新機能の紹介ではありません。データベースの「限界」という概念そのものを過去のものにする、新時代の幕開けの記録です。

第1章：Amazon Auroraとは？ – Limitless Databaseの基盤を理解する

Limitless Databaseの革新性を理解するためには、まずその基盤であるAmazon Auroraのアーキテクチャを深く知る必要があります。Auroraはなぜ「クラウドのために再設計されたリレーショナルデータベース」と呼ばれるのでしょうか。

1.1 アーキテクチャの核心：コンピュートとストレージの分離

従来のモノリシックなデータベースでは、クエリを処理するコンピュート層と、データを永続化するストレージ層が密結合していました。これに対し、Auroraはこれらを完全に分離し、それぞれを独立して最適化・スケールさせることを可能にしました。

コンピュート層（DBインスタンス）: ユーザーが直接接続し、SQLクエリを実行する部分です。書き込みを担当する「ライターインスタンス」が1台と、読み取りを担当する最大15台の「リーダーインスタンス（リードレプリカ）」で構成されます。
ストレージ層（クラスターボリューム）: Auroraの真の革新がここにあります。データは単一のディスクに保存されるのではなく、ログ構造（Log-structured）の分散ストレージシステムとして実装されています。データブロックやREDOログは、3つのアベイラビリティゾーン（AZ）にまたがって、それぞれ2つずつ、合計6つのコピーが作成されます。

このアーキテクチャがもたらす最大の利点は、データベースのI/O処理のあり方を根本から変えたことです。従来のデータベースでは、トランザクションがコミットされると、データページ、トランザクションログ、バイナリログなど、複数の書き込みがストレージに対して発生していました。Auroraでは、コンピュート層はREDOログレコードをストレージ層に送信するだけです。実際のデータページの書き込みやバックグラウンド処理は、インテリジェントなストレージ層が非同期で効率的に行います。これにより、書き込みレイテンシーが大幅に削減され、スループットが向上するのです。

1.2 Auroraがもたらした主要な利点

この独自のアーキテクチャにより、Auroraは以下の利点を実現しました。

パフォーマンスとスケーラビリティ: 標準的なMySQLの最大5倍、PostgreSQLの最大3倍のパフォーマンスを謳っています。また、リードレプリカを最大15台まで追加することで、読み取り性能を容易にスケールアウトできます。
高可用性と耐久性: データが6つのコピーで保護され、最大2つのコピーを失っても書き込み可用性を、最大3つのコピーを失っても読み取り可用性を維持できます。ライターインスタンスに障害が発生した場合でも、通常は30秒以内にリードレプリカの1つが新たなライターに昇格し、フェイルオーバーが完了します。
コスト効率: ストレージは使用した分だけ課金され、最大128TiBまで自動的に拡張します。高価なSANストレージは不要です。
マネージドサービスの利便性: プロビジョニング、パッチ適用、バックアップ、リカバリ、モニタリングといった煩雑な管理タスクはすべてAWSにオフロードできます。

1.3 ここまでのAuroraの限界点：書き込みスケーラビリティの壁

これほどまでに優れたAuroraですが、唯一、構造的な限界がありました。それは書き込み性能が単一のライターインスタンスの性能に依存するという点です。CPU、メモリ、ネットワーク帯域といった物理リソースが、データベース全体の書き込みスループットの上限を決定していました。

この上限を超えるワークロードに対応するには、結局のところ、複数のAuroraクラスターを用意し、アプリケーション側でデータを分割して振り分ける「手動シャーディング」に頼らざるを得ませんでした。これは、まさにAuroraが解決しようとしていた複雑さへの回帰であり、開発者と運用者にとって大きな負担となっていました。

この最後の壁、すなわち「書き込みのスケールアウト」という長年の課題に、AWSが出した答えこそが、Amazon Aurora Limitless Databaseなのです。

第2章：【本題】Amazon Aurora Limitless Databaseとは何か？

Amazon Aurora Limitless Databaseは、単一データベースのシンプルさと使いやすさを維持したまま、ペタバイト級のデータと毎秒数百万の書き込みトランザクションを処理できるように設計された、新しいスケーラビリティ機能です。その本質は、これまで開発者と運用者が手動で行っていたシャーディングのあらゆる複雑さを、データベースエンジン自身が完全に抽象化し、自動化することにあります。

ユーザーは、あたかも巨大な単一のAuroraデータベースを操作しているかのように感じますが、その背後では、データが複数のサーバーに自動的に分散され、並列処理されています。

2.1 アーキテクチャの核心：分散トランザクションプレーンとシャーデッドストレージ

Limitless Databaseの魔法を実現しているのは、主に2つの新しいコンポーネントからなる精巧なアーキテクチャです。

トランザクションルーター (Transaction Router)
データベースシャード (Database Shard)

これらをつなぎ合わせ、全体として一貫性を保つ役割を担うのが、目には見えない分散トランザクションプレーンです。

(概念図：AWS公式ドキュメントより引用)

それでは、各コンポーネントの役割を詳しく見ていきましょう。

1. トランザクションルーター (Transaction Router)

トランザクションルーターは、Limitless Databaseの「頭脳」であり、アプリケーションからのすべての接続を受け付ける単一のエンドポイントです。その主な役割は以下の通りです。

SQLパーシングとルーティング: アプリケーションから受け取ったSQLクエリを解析し、そのクエリがどのデータベースシャードで処理されるべきかを判断します。この判断のために、ルーターはどのデータがどのシャードに存在するかというメタデータをキャッシュしています。
トランザクションの調整 (Coordination): クエリが複数のシャードにまたがる場合（クロスシャードクエリ）、トランザクションルーターはコーディネーターとして機能します。各シャードに必要なクエリを送信し、結果を集約し、トランザクション全体がアトミックに（すべて成功するか、すべて失敗するかのいずれか）完了することを保証します。
透過的な接続管理: アプリケーションは、背後に多数のシャードが存在することを意識する必要がありません。標準的なPostgreSQLのクライアントドライバを使って、単一のデータベースに接続するのと同じようにトランザクションルーターに接続するだけです。

トランザクションルーター自体もステートレスに設計されており、複数台で構成することで高い可用性とスケーラビリティを確保しています。これにより、Limitless Databaseの入り口が単一障害点になることを防いでいます。

2. データベースシャード (Database Shard)

データベースシャードは、実際にデータを格納し、クエリを実行する「手足」となる部分です。Limitless Databaseにおける各シャードは、独立したAurora PostgreSQLクラスターそのものです。つまり、各シャードはそれ自体がライターインスタンスと複数のリーダーインスタンスを持つ、高可用で高性能なデータベース単位なのです。

データの保存と処理: テーブルのデータは、後述するシャーディングキーに基づいて分割され、各シャードに分散して保存されます。トランザクションルーターから送られてきたクエリは、各シャード内のライターインスタンスまたはリーダーインスタンスで実行されます。
独立したスケーリング: 各シャードは独立したAuroraクラスターであるため、個別にインスタンスサイズを変更したり、リードレプリカを追加したりすることが可能です。
従来のAuroraの能力: 各シャードはAuroraの恩恵（高性能ストレージ、高速フェイルオーバー、継続的バックアップなど）をすべて享受できます。

Limitless Databaseは、これらのデータベースシャードを必要に応じて追加（スケールアウト）することで、全体の書き込み性能とストレージ容量をリニアに拡張していくのです。

3. 分散トランザクションプレーン (Distributed Transaction Plane)

複数の独立したデータベースシャードを、あたかも単一のデータベースであるかのように見せるための最も重要な技術が、この分散トランザクションプレーンです。これは、トランザクションの一貫性（ACID特性）を分散環境で保証するための仕組みです。

分散トランザクションで伝統的に用いられてきたのが「2フェーズコミット（2PC）」プロトコルです。しかし、2PCはコーディネーターに障害が発生した場合に全参加者がブロックされてしまう可能性があるなど、パフォーマンスと可用性の面で課題を抱えています。

Limitless Databaseは、これに対してより効率的で耐障害性の高い、独自のアトミックコミットプロトコルを採用していると推測されます。トランザクションルーターがコーディネーターとなり、各シャードでの処理状況を監視し、すべてのシャードでコミット準備が完了したことを確認してから、最終的なコミット命令を全シャードに送信します。もし途中でいずれかのシャードが失敗した場合は、即座に全シャードにロールバックを指示します。この一連のプロセスが高速かつ堅牢に行われることで、ユーザーは分散を意識することなく、安心してトランザクショナルな操作を実行できるのです。

2.2 データ分散の仕組み：シャーディングキーと自動リシャーディング

Limitless Databaseの性能を最大限に引き出すためには、データをいかに効率的にシャードへ分散させるかが鍵となります。この中心的な役割を担うのが「シャーディングキー」です。

シャーディングキーの指定: ユーザーは、テーブルを作成する際に、どの列をシャーディングキーとして使用するかをSHARD KEY句で指定します。
sql CREATE TABLE products ( product_id UUID, product_name TEXT, category TEXT, price NUMERIC ) SHARD KEY (product_id);
この例では、product_idがシャーディングキーとなります。Limitless Databaseは、このproduct_idの値のハッシュ値を計算し、その結果に基づいて、どのシャードにその行のデータを格納するかを決定します。
自動リシャーディング（シャード分割）: Limitless Databaseの最も強力な機能の一つが、運用を自動化するシャード分割機能です。あるシャードのデータサイズが大きくなりすぎたり、I/O負荷が高くなりすぎたりすると（いわゆる「ホットシャード」）、システムはこれを自動的に検知します。そして、そのシャードを2つの新しいシャードにオンラインで分割し、データを再配置します。このプロセスは、アプリケーションに対して透過的に行われ、サービスのダウンタイムを発生させません。メタデータが更新され、トランザクションルーターは新しいシャード構成を即座に認識し、クエリを適切にルーティングし始めます。

この自動リシャーディング機能により、運用者はもはやシャードの容量監視や手動でのデータ移行といった煩雑な作業から完全に解放されるのです。

第3章：Limitless Databaseの主要な機能と利点

Limitless Databaseがもたらす価値は、単なる性能向上にとどまりません。それは、データベースに関わるすべてのステークホルダー（開発者、DBA、インフラ管理者）の体験を根底から変革するものです。

3.1 圧倒的な書き込みスケーラビリティ

これがLimitless Databaseの最も注目すべき利点です。理論上、データベースシャードを追加し続けることで、書き込み性能とストレージ容量を無限にスケールアウトできます。AWSは、ペタバイト級のデータを管理し、毎秒数百万の書き込みトランザクションを処理できると述べています。

これまで、このような規模のワークロードを実現するには、NoSQLデータベースを選択するか、あるいはリレーショナルデータベースで極めて複雑な手動シャーディングを実装するしかありませんでした。Limitless Databaseは、リレーショナルモデルの厳格な一貫性と使い慣れたSQLを維持したまま、NoSQLに匹敵するスケーラビリティを提供します。

3.2 運用負荷の劇的な削減

手動シャーディングは悪夢のような運用負荷を伴います。
* シャードの追加、分割、統合は手作業であり、長時間のメンテナンスウィンドウが必要。
* データが均等に分散されず、ホットスポットが発生すると手動でのデータ移動が必要。
* シャード構成の変更は、アプリケーションの構成変更も必要とする。

Limitless Databaseは、これらすべてを自動化します。
* 手動シャーディングからの解放: シャードのプロビジョニング、データの分散、リシャーディング（シャード分割）はすべてデータベースエンジンが自律的に行います。
* アプリケーションコードのシンプル化: アプリケーションはシャーディングロジックを持つ必要がありません。どのデータがどこにあるかを意識せず、単一のデータベースエンドポイントにクエリを投げるだけです。
* 自動スケーリングによる運用自動化: ワークロードの増加に応じてシステムが自動的にシャードを追加し、スケールアウトします。ピーク時に合わせた過剰なプロビジョニングが不要になり、コスト効率も向上します。

3.3 単一データベースとしての使いやすさ

開発者にとっての最大のメリットは、分散システムを扱っているという複雑さを感じさせないことです。

標準SQLインターフェース: Limitless DatabaseはPostgreSQLと互換性があります。既存のツール、ドライバ、フレームワークをそのまま利用できます。新しいAPIを学習する必要はありません。
クロスシャードクエリのサポート: トランザクションルーターが複数のシャードにまたがるクエリを自動的に調整し、結果をまとめて返します。JOINや集計関数なども、シャードをまたいで実行可能です（パフォーマンス上の考慮は必要）。
分散を意識させない開発体験: 開発者はデータモデリングとビジネスロジックに集中できます。インフラの物理的な制約を意識する必要性が大幅に低下します。

3.4 トランザクション一貫性の維持

スケーラビリティのために一貫性を犠牲にする、いわゆる「結果整合性」モデルを選択するシステムも多い中、Limitless Databaseはリレーショナルデータベースの魂であるACID特性を分散環境でも完全にサポートします。これにより、金融取引や在庫管理など、データの正確性が絶対的に求められるミッションクリティカルなアプリケーションでも、安心して利用することができます。

第4章：ユースケースと導入シナリオ

Limitless Databaseは、どのような分野でその真価を発揮するのでしょうか。ここでは、具体的なユースケースをいくつか見ていきましょう。

4.1 大規模マルチプレイヤーオンラインゲーム (MMOG)

MMOGの世界では、数百万人のプレイヤーが同時に活動し、膨大な量のデータ（プレイヤー情報、アイテム、位置情報、チャットログ）がリアルタイムに生成・更新されます。特に人気タイトルのローンチ時や大型イベント時には、書き込み負荷が爆発的に増加します。Limitless Databaseは、プレイヤーIDをシャーディングキーとすることで、プレイヤーデータを各シャードに分散させ、書き込み負荷をスケールアウトできます。これにより、サーバーの遅延やダウンを防ぎ、快適なゲーム体験を提供できます。

4.2 IoTプラットフォーム

何億ものセンサーやデバイスから、毎秒大量の時系列データが送信されるIoTの世界は、データベースにとって最も過酷な環境の一つです。デバイスIDをシャーディングキーにすることで、Limitless Databaseは流入するデータを効率的に複数のシャードに分散し、リアルタイムでの取り込みを可能にします。取り込まれたデータに対して、複雑な分析クエリを実行できるのも、SQLをサポートするLimitless Databaseの強みです。

4.3 金融サービス

株式取引システムや決済ゲートウェイは、1ミリ秒の遅延が大きな損失につながる世界です。毎秒数百万件のトランザクションを、絶対的な正確性をもって処理する必要があります。Limitless Databaseは、その高い書き込みスループットと厳格なACID保証により、これらの要求に応えることができます。取引IDや顧客IDでシャーディングすることで、システム全体のスループットを向上させつつ、個々の取引の整合性を保証します。

4.4 Eコマースおよびリテール

ブラックフライデーやサイバーマンデーのような大規模セールイベントでは、注文処理システムの負荷が平常時の数千倍に達することもあります。従来は、このピークに合わせて巨大なデータベースをプロビジョニングする必要があり、コストの無駄が生じていました。Limitless Databaseなら、負荷に応じて自動的にスケールアウトし、イベント終了後にはスケールインすることで、需要に合わせた柔軟かつコスト効率の高いインフラを実現できます。注文テーブルを注文IDでシャーディングすれば、書き込みの競合を最小限に抑えることができます。

4.5 急成長するSaaSアプリケーション

マルチテナント型のSaaSアプリケーションでは、顧客（テナント）が増えるにつれてデータ量が線形に増加していきます。テナントIDをシャーディングキーにすることで、各テナントのデータを論理的・物理的に分離しつつ、プラットフォーム全体のスケーラビリティを確保できます。「うるさい隣人（Noisy Neighbor）」問題、つまり特定のヘビーユーザーの負荷が他のユーザーに影響を与える問題も、シャード単位でリソースを分離することで緩和できます。

第5章：他の分散データベースや手法との比較

Limitless Databaseの立ち位置をより明確にするため、他のアプローチと比較してみましょう。

手動シャーディングとの比較: 言うまでもありません。Limitless Databaseは、手動シャーディングの複雑性、運用コスト、開発者の負担、そしてヒューマンエラーのリスクを劇的に削減します。これは、馬車と自動車を比較するようなものです。
Vitess, Citus Dataなどとの比較: これらはMySQLやPostgreSQLにシャーディング機能を追加するオープンソースのミドルウェアです。非常に強力なツールですが、導入・運用には専門的な知識が必要であり、インフラの管理責任はユーザー側にあります。Limitless Databaseは、これらの機能をフルマネージドのサービスとして提供し、AWSエコシステム（IAM, CloudWatch, KMSなど）と完全に統合されている点が大きな違いです。
Google Cloud Spanner, CockroachDBなどとの比較: これらは「NewSQL」や「分散SQL」と呼ばれるカテゴリのデータベースで、最初から分散システムとして設計されています。アーキテクチャや思想はLimitless Databaseと共通する部分も多いですが、いくつかの重要な違いがあります。
- アーキテクチャ: SpannerやCockroachDBはコンピュートとストレージが一体化したシェアードナッシング（Shared-nothing）アーキテクチャが基本ですが、Limitless DatabaseはAuroraのコンピュート・ストレージ分離アーキテクチャを継承しています。これにより、ストレージ層の管理がよりシンプルになる可能性があります。
- 互換性: Limitless Databaseは既存のAurora PostgreSQLとの高い互換性を目指しており、既存のアプリケーションからの移行が比較的容易であると考えられます。一方、Spannerなどは独自のSQL方言やトランザクションモデルを持つ場合があり、学習コストや移行コストが発生することがあります。
- エコシステム: AWSユーザーにとって、既存のAWSサービスとのシームレスな連携は大きな利点です。

Limitless Databaseは、「使い慣れたAuroraの延長線上で、極限のスケーラビリティを手に入れる」という、非常に魅力的な選択肢を提供していると言えるでしょう。

第6章：導入に向けた考慮事項とベストプラクティス

Limitless Databaseは強力なツールですが、その性能を最大限に引き出すためには、分散データベース特有の設計原則を理解しておくことが重要です。

6.1 最重要設計項目：シャーディングキーの選定

Limitless Databaseのパフォーマンスは、シャーディングキーの選び方で決まると言っても過言ではありません。

カーディナリティ: シャーディングキーとして選ぶ列は、値の種類が非常に多い（カーディナリティが高い）必要があります。例えば、user_idやproduct_id、order_idは良い候補です。逆に、「性別」や「都道府県」のような値の少ない列を選ぶと、特定のシャードにデータが集中し、ホットスポットの原因となります。
アクセスパターン: 最も頻繁にアクセスされるクエリが、シャーディングキーをWHERE句に含んでいることが理想です。これにより、トランザクションルーターはクエリを単一のシャードに直接ルーティングでき、最も高速に応答できます。
書き込み分散: 書き込みが集中するようなキー（例：常に最新のIDに書き込むなど）は避け、書き込みがすべてのシャードに均等に分散されるようなキーを選ぶべきです。UUIDのようなランダムな値は、この点で優れています。

一度選んだシャーディングキーを変更するのは非常に困難なため、アプリケーションの設計段階で慎重に検討する必要があります。

6.2 データモデリングとクエリの最適化

データのコロケーション (Colocation): 関連性の高いデータ、例えば「顧客情報」と「その顧客の注文情報」は、同じシャーディングキー（この場合はcustomer_id）を使うことで、同じシャードに配置（コロケーション）できます。これにより、これらのテーブルをJOINするクエリは単一シャード内で完結し、非常に高速に実行できます。
クロスシャードクエリのコスト: シャーディングキーを含まないクエリや、複数のシャードにまたがるJOINは、トランザクションルーターがすべてのシャードにクエリをブロードキャストし、結果を集約する必要があるため、レイテンシーが大きくなり、コストも高くなります。このようなクエリは避けられない場合もありますが、その性能特性を理解した上で利用することが重要です。

6.3 プレビュー版の制約と今後の展望

本記事執筆時点（2024年）で、Amazon Aurora Limitless Databaseはまだプレビュー段階です。これは、本番環境での利用は推奨されず、機能にもいくつかの制約があることを意味します。例えば、サポートされるのはAurora PostgreSQL互換エディションのみで、MySQL互換エディションはまだです。また、利用できるリージョンやインスタンスタイプも限られています。

今後、一般提供（General Availability, GA）に向けて、機能の拡充（MySQLサポートなど）、パフォーマンスのさらなる最適化、対応リージョンの拡大などが期待されます。プレビュー期間は、この新しい技術を評価し、将来のアーキテクチャ設計にどう活かせるかを検討する絶好の機会と言えるでしょう。

まとめ：データベースの未来を切り拓くLimitless Database

私たちは今、データベース技術の歴史における大きな転換点に立っています。長年にわたり、開発者とインフラ管理者を悩ませてきた「スケーラビリティの壁」と「運用の複雑さ」という二律背反の課題。Amazon Aurora Limitless Databaseは、この根源的な問題を、クラウドネイティブなアプローチで見事に解決しようとしています。

開発者にとって: Limitless Databaseは、分散システムの複雑さを抽象化し、インフラの制約から解放された、真に創造的なアプリケーション開発を可能にします。もう、シャーディングロジックのためにコードを汚す必要はありません。
インフラ管理者にとって: Limitless Databaseは、自律的なスケーリングとリシャーディングにより、手動での煩雑な運用タスクを過去のものにします。インフラは、ビジネスの成長に合わせて、静かに、そして自動的に追従していきます。

リレーショナルデータベースの堅牢な一貫性と、NoSQLデータベースの無限のスケーラビリティ。この二つを、使い慣れたSQLインターフェースとフルマネージドの利便性のもとで両立させる。これは、多くのエンジニアが夢見てきたデータベースの理想形の一つと言えるでしょう。

もちろん、すべてのワークロードにLimitless Databaseが必要なわけではありません。しかし、ハイパースケールなデータとトランザクションが当たり前になるこれからの時代において、この技術がデータベース設計の新たな常識となる可能性は十分にあります。

Amazon Aurora Limitless Databaseは、データベースから「限界」という言葉を奪い去ろうとしています。その挑戦が完全に成功したとき、我々の作るシステムの可能性は、まさに無限（Limitless）に広がっていくことでしょう。データベースの新時代の幕開けです。