クラウドが万能なはずはない！Azureの弱点を暴け（前編）

　★Azureへの移行はこんなに簡単！支援策に関する情報はこちら

SQLデータベースとIaaSで動かすSQL Serverの特性を理解せよ

　谷川：前回の座談会では予想に反し、意外と苦労なくMicrosoft Azure（以下、Azure）でSQL Serverが使えるという結論になったんです。なので、今回はもう少し現実的な、移行作業に伴う苦労や注意点を掘り起こしてみたいと思います。まずは小澤さんから見てAzureはどうですか？

　小澤：AzureだとSQL Serverがそのまま使えるのがメリットですね。SQLデータベースとの使い分けは気になるところです。

　谷川：SQLデータベースは数年前に比べ、かなり良くなっていると聞きます。

　小澤：たとえば先月には、SQLデータベースでデータ圧縮がサポートされました。データ圧縮はSQL Serverではエンタープライズエディションでしかサポートされていない機能です。エンタープライズエディションでしかサポートされていない機能の代表的なものとしては、オンラインでのインデックス再構築もあるのですが、こちらについてもSQLデータベースについては以前からどのエディションでも使用することができました。オンプレミスのSQL Serverにはエディションで機能制限があるのに、SQLデータベースにはそれがない。さまざまな機能が、デフォルトで使えます。Azureでは、SQLデータベースを使うよう誘導してもいいような気がします。

　笹木：私もいいと思います。前回も出ましたがSQLデータベースはサービスです。対するSQL Serverはプロダクトという違いがあります。それぞれをどう使うかは、ユーザーが選ぶことになります。

　小澤：特性を選ぶのが大事ですね。Azureを使うユーザーがSQLデータベースとSQL Serverのどちらを選ぶか。MSはどういう戦略で進めているのですか？

　谷川：使い分けるためのガイドライン的なものはありますか？

　笹木：既存のSQL Server を使いたいなら IaaS、オンプレとは異なる新しいアーキテクチャーでサービスとして使いたいなら SQL データベースになります。ただ、どちらかではなく、どちらもやりますというのが我々のスタンスです。

　小澤：「どちらもできます」なのかな。まだこの場には現れていませんが、SQL Serverのプロダクトの担当である北川さん的にはどちらを目指しているのかな？

　笹木：SQL Serverでしょうね…。

　小澤：ちょっと疑問があります。SQLデータベースには150GBの制限があります。一方でSQL Serverは16TBくらいまでいけますよね。両方に容量150GBのデータを載せて比べたら、どうなるのでしょうか。

　笹木：場合によるでしょうね。SQLデータベースは基本的にOLTP向けです。オンライン処理で比較すると、SQLデータベースはスケールアウトすればいくらでもパフォーマンスを出せる（4/8 追記：但し、データベースにアクセスするアプリケーション及び業務処理が業務特性に合わせた "カスタム シャーディング" を実行できるアーキテクチャーになっており、多数のデータベースでデータを水平分割できるように設計・実装する必要があります）。かたやバッチ処理で使うならば、SQLデータベースは向いていません。

　谷川：その理由は？

　笹木：基本的な制約として、リソースを大量に消費するロングトランザクションを実行するとコネクションが切られます。例えば100万件を超えるロックを1トランザクションで確保することはできません。だから長時間かかるバッチ処理が流せません。つまり、リソースを占有するバッチ処理には向いていないのです。

　小澤：強みもあると思います。SQLデータベースは誰が使ってもデータが3重化され冗長化されているのが強みです。SQLデータベースならSQL ServerでAlwaysOnを組んで実現するような難しいことを、簡単にできるのがメリットですね。