“フルマネージド” の新たな基準を確立する BigQuery
2016年9月5日月曜日
* この投稿は米国時間 8 月 22 日、BigQuery Technical Program Manager である Tino Tereshko によって投稿されたもの（投稿はこちら）の抄訳です。
データ プロフェッショナルにとって、クラウド ベースの分析ウェアハウスのマネージド サービスには選択肢がたくさんあります。Google BigQuery のテクニカル プログラム マネジャーである私の意見にはバイアスがかかっているかもしれませんが、そうした中で競合サービスを見ると、BigQuery の管理性はやはり際立っています。
クラウド分析サービスに関しては、“フルマネージド” という言葉はかなり広い意味で使われる傾向があります。しかし、すべてのクラウド データ ウェアハウスが同じように作られているわけではありません。
BigQuery のユニークなサーバーレス アーキテクチャでは、「フルマネージド技術とは何か」という基準が高く設定されています。その結果として BigQuery ユーザーは、常に改良され、シームレスなスケーラビリティを備え、高速で信頼性の高いサービスの恩恵を受けることができるのです。
BigQuery のアーキテクチャはどのようなものか、それがどのようにエンドユーザーにとっての管理性の高さにつながるのか、以下で見ていきましょう。
BigQuery は、データをロードして SQL コマンドを実行するだけで使い始めることができます。クラスタの作成、デプロイ、プロビジョニングは必要ありません。仮想マシン（VM）、ストレージ、ハードウェア リソースのサイジングも不要です。ディスクのセットアップ、レプリケーションの定義、圧縮や暗号化の構成といったことを行う必要もありません。
ユーザーは、数十ペタバイト規模への、そしてゼロへのスケーリングをシームレスに行えます。BigQuery の担当エンジニアが、この規模に到達するのに必要なリソースをすでにデプロイ済みだからです。
そのため、スケーリングを行うには、より大規模なクラスタをプロビジョニングするのではなく、BigQuery をより大規模に使用するだけでよいのです。ベスト プラクティスと使用量のクォータ（割り当て）に注意するだけで済みます。
そして、継続的にストレージを調査して最適化するバックグラウンド プロセスが内部で動作しています。BigQuery ユーザーは、こうした内部的な複雑さを意識せずに済みます。
BigQuery には、プライマリ キーやソート キー、インデックス、分散キーといった概念がありません。そのため、データベース管理はシンプルです。パーティション テーブルを定義し、コストの観点から最適化するだけです。ことによると、データ シャーディング戦略を採用するという手もあるかもしれません。
Colossus ストレージは、ペタビット / 秒クラスの Jupiter ネットワークで実行エンジンの Dremel と接続されています。これにより、BigQuery はインメモリ データベースならではのパフォーマンスを発揮します。Dremel は最新版で SQL クエリをインメモリで実行するようになりました。
データ プロフェッショナルにとって、クラウド ベースの分析ウェアハウスのマネージド サービスには選択肢がたくさんあります。Google BigQuery のテクニカル プログラム マネジャーである私の意見にはバイアスがかかっているかもしれませんが、そうした中で競合サービスを見ると、BigQuery の管理性はやはり際立っています。
クラウド分析サービスに関しては、“フルマネージド” という言葉はかなり広い意味で使われる傾向があります。しかし、すべてのクラウド データ ウェアハウスが同じように作られているわけではありません。
BigQuery のユニークなサーバーレス アーキテクチャでは、「フルマネージド技術とは何か」という基準が高く設定されています。その結果として BigQuery ユーザーは、常に改良され、シームレスなスケーラビリティを備え、高速で信頼性の高いサービスの恩恵を受けることができるのです。
BigQuery のアーキテクチャはどのようなものか、それがどのようにエンドユーザーにとっての管理性の高さにつながるのか、以下で見ていきましょう。
デプロイとスケーリング
BigQuery は内部的に、Dremel、Colossus、Jupiter、Borg といった Google の低レベル インフラストラクチャ技術に支えられた多数のマルチテナント サービス セットを採用しています。BigQuery は、データをロードして SQL コマンドを実行するだけで使い始めることができます。クラスタの作成、デプロイ、プロビジョニングは必要ありません。仮想マシン（VM）、ストレージ、ハードウェア リソースのサイジングも不要です。ディスクのセットアップ、レプリケーションの定義、圧縮や暗号化の構成といったことを行う必要もありません。
ユーザーは、数十ペタバイト規模への、そしてゼロへのスケーリングをシームレスに行えます。BigQuery の担当エンジニアが、この規模に到達するのに必要なリソースをすでにデプロイ済みだからです。
そのため、スケーリングを行うには、より大規模なクラスタをプロビジョニングするのではなく、BigQuery をより大規模に使用するだけでよいのです。ベスト プラクティスと使用量のクォータ（割り当て）に注意するだけで済みます。
データベース管理
BigQuery は、ストレージ システムの Colossus 上でカラムナ ストレージ フォーマットの Capacitor を採用しており、パフォーマンスと耐久性に最適化された独自の方法でお客様のデータを書き込みます。そして、継続的にストレージを調査して最適化するバックグラウンド プロセスが内部で動作しています。BigQuery ユーザーは、こうした内部的な複雑さを意識せずに済みます。
BigQuery には、プライマリ キーやソート キー、インデックス、分散キーといった概念がありません。そのため、データベース管理はシンプルです。パーティション テーブルを定義し、コストの観点から最適化するだけです。ことによると、データ シャーディング戦略を採用するという手もあるかもしれません。
Colossus ストレージは、ペタビット / 秒クラスの Jupiter ネットワークで実行エンジンの Dremel と接続されています。これにより、BigQuery はインメモリ データベースならではのパフォーマンスを発揮します。Dremel は最新版で SQL クエリをインメモリで実行するようになりました。
アップグレードとメンテナンス
BigQuery には毎週改良が加えられています。さらに、Google は頻繁にインフラストラクチャのリソースを増強し、メンテナンスを実施しています。
これらはすべてバックグラウンドで行われます。ユーザーは介在せず、アップグレードやメンテナンスに付き物のダウンタイムは発生しません。ユーザーから見ると、物事がより簡単になり、高速になり、安くなるだけです。
2012 年に初めてリリースされて以来、BigQuery は多くのマイルストーンに到達してきました。この 1 年だけでも、以下のように基幹コンポーネントの改良が進んでいます。
SRE は、社内 SLO（サービス レベル目標）に照らして BigQuery を追跡します。社内 SLO は多くの場合、パブリック SLA よりもはるかに厳格です。また私たちは、あまり明確でない SQL の問題に関するお客様の調査も支援できます。
BigQuery チームは舞台裏で、素晴らしいインフラストラクチャで動作する最新のソフトウェア スタックをお客様が利用できるようにサポートしています。そのために、お客様のクエリを別のデータセンターにシームレスに移行することもあります（その場合はもちろん、たとえば欧州内など、お客様が設定したデータセットの場所を尊重したうえで移行します）。
これは、お客様の BigQuery クエリが、午前にはお客様のリージョン内のあるデータセンターで実行され、午後には別のデータセンターで実行される可能性があるということです。それは、私たちが Dremel の新バージョンを展開したり、ネットワークやハードウェアをアップグレードしたり、新しい圧縮アルゴリズムを実装したりすることがあるからです。
BigQuery は、“フルマネージド” の意味の枠を押し広げ続けます。それは BigQuery ユーザーにとって、複雑さが軽減され、タスクが減り、分析がより迅速にできるということを意味します。
インフラストラクチャやスケーリング、オペレーション、セキュリテイ、信頼性を気にする時間が少なくなり、データの理解や興味深いインサイトの導出、データに基づいた意思決定によるビジネスのサポートに、より多くの時間をかけることができます。手段としての行動ではなく、目的のための行動に取り組めるのです。
BigQuery についてさらに詳しく知りたい方は、サンプルのパブリック データセットをご覧になることをお勧めします。無料サービスをぜひご活用ください！
- Posted by Tino Tereshko, BigQuery Technical Program Manager
これらはすべてバックグラウンドで行われます。ユーザーは介在せず、アップグレードやメンテナンスに付き物のダウンタイムは発生しません。ユーザーから見ると、物事がより簡単になり、高速になり、安くなるだけです。
BigQuery チームが行ってきた改良の月間件数
2012 年に初めてリリースされて以来、BigQuery は多くのマイルストーンに到達してきました。この 1 年だけでも、以下のように基幹コンポーネントの改良が進んでいます。
- Dremel : 新しいインメモリの実行エンジン
- Capacitor : 次世代ストレージ エンジン
- Poseidon : 新しいデータ インジェスト エンジン
- 長期保存 : 90 日以上エディットされていないデータの保存料金が 50 % 割引
- まったく新しいワーク スケジューリング サービス : 動的なパイプライン実行など
信頼性
BigQuery は、地理的に分散したサイト信頼性エンジニア（SRE）チームが担当しています。このチームは 24 時間週 7 日、BigQuery で停止、パフォーマンス低下、レイテンシ、障害を監視します。SRE は、社内 SLO（サービス レベル目標）に照らして BigQuery を追跡します。社内 SLO は多くの場合、パブリック SLA よりもはるかに厳格です。また私たちは、あまり明確でない SQL の問題に関するお客様の調査も支援できます。
BigQuery チームは舞台裏で、素晴らしいインフラストラクチャで動作する最新のソフトウェア スタックをお客様が利用できるようにサポートしています。そのために、お客様のクエリを別のデータセンターにシームレスに移行することもあります（その場合はもちろん、たとえば欧州内など、お客様が設定したデータセットの場所を尊重したうえで移行します）。
これは、お客様の BigQuery クエリが、午前にはお客様のリージョン内のあるデータセンターで実行され、午後には別のデータセンターで実行される可能性があるということです。それは、私たちが Dremel の新バージョンを展開したり、ネットワークやハードウェアをアップグレードしたり、新しい圧縮アルゴリズムを実装したりすることがあるからです。
BigQuery は、“フルマネージド” の意味の枠を押し広げ続けます。それは BigQuery ユーザーにとって、複雑さが軽減され、タスクが減り、分析がより迅速にできるということを意味します。
インフラストラクチャやスケーリング、オペレーション、セキュリテイ、信頼性を気にする時間が少なくなり、データの理解や興味深いインサイトの導出、データに基づいた意思決定によるビジネスのサポートに、より多くの時間をかけることができます。手段としての行動ではなく、目的のための行動に取り組めるのです。
BigQuery についてさらに詳しく知りたい方は、サンプルのパブリック データセットをご覧になることをお勧めします。無料サービスをぜひご活用ください！
- Posted by Tino Tereshko, BigQuery Technical Program Manager
0 件のコメント :
コメントを投稿