Data Analytics OnAir / Database OnAir でAlloyDBの分析基盤での活用について登壇しました

<html><head></head><body><p>こんにちは、エンジニアの oga です。</p>
<p>5/12(日本時間)にGoogle I/Oで <a href="https://cloud.google.com/alloydb/" target="_blank" rel="noreferrer">AlloyDB</a> と呼ばれる新しいデータベースプロダクトがアナウンスされました。<br>
アナウンスブログ: <a href="https://cloud.google.com/blog/ja/products/databases/introducing-alloydb-for-postgresql" target="_blank" rel="noreferrer">AlloyDB for PostgreSQL を発表：高額なレガシー データベースからの解放 | Google Cloud Blog</a></p>
<p>PLAIDでは、Private previewの段階で紹介をして頂き非常に興味深いものだったのでpreviewに参加して検証を行なっていて、以下の様なコメントを寄稿させて頂きました。<br>
<img src="https://ik.imagekit.io/plaid/3108b9ec-ad62-483a-ab17-f622e7b0522c/1000x1000/alloydb_plaid_quote.png" alt="alloydb_plaid_quote.png"><br>
<a href="https://www.youtube.com/watch?v=o5pKfH0Tonw" target="_blank" rel="noreferrer">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>以下和訳</p>
<blockquote>
<p>「PLAID では CX (顧客体験) プラットフォーム KARTE を企業向けに開発・提供しています。KARTE は膨大な行動ログから深い洞察を得る先進的なリアルタイム分析機能を持ち、顧客に合わせた最適なコミュニケーションを可能にしています。AlloyDB は PostgreSQL と完全互換であり、透過的に列方向処理を行うことができます。私たちはこれが新しく強力なオプションであると捉えており、OLTP・OLAP・HTAP と分断されたワークロードを統合したシステムデザインを最小限の追加知識で実現する、ユニークな技術的アプローチであると考えています。将来的には Google Cloud の他の強力なデータベース サービスとの連携も強化され、私たちのKARTEが提供する分析機能において、より優れたパフォーマンス、スケーラビリティ、拡張性をもたらすことを期待しています。」</p>
</blockquote>
<p>この記事では、AlloyDBの特徴とPLAIDで今後どの様に使っていきたいかをご紹介します。</p>
<hr>
<section class="widget widget-text">
	<div id="toc"></div>
</section>
<style>
    div#toc ol {
        margin: 0 0 0 25px;
    }
    div#toc ol li {
        margin: 0;
        padding: 1px;
        list-style-type: disc;
    }
</style>
<hr>
<h2 id="はじめに">はじめに</h2>
<p>AlloyDBはPreviewフェーズである為、今後の機能追加や仕様変更も多く発生すると思われます。<br>
この記事では、現時点の仕様情報とそれに基づく見解を記載しています。<br>
<strong>最新の情報は必ず<a href="https://cloud.google.com/alloydb/docs/overview" target="_blank" rel="noreferrer">GCPの公式ドキュメント</a>をご確認下さい。</strong></p>
<h2 id="AlloyDBの特徴">AlloyDBの特徴</h2>
<ul>
<li>PostgreSQLとの完全互換</li>
<li>高パフォーマンス</li>
<li>columnar engine（高速なOLAP）</li>
<li>柔軟で高い可用性を持った構成</li>
<li>機械学習による自動化されたリソース管理</li>
<li>シンプルな料金体系</li>
</ul>
<h3 id="PostgreSQLとの完全互換">PostgreSQLとの完全互換</h3>
<p>文字通り、PostgreSQLを使用するアプリケーションやエコシステムはAlloyDBで変更する必要無くそのまま適用することができます。<br>
弊社ではそういったアプリケーションは無かったものの、検証においてCLI,GUIツールなど今まで培われてきたPostgreSQLのものをそのまま使用でき、<br>
開発や運用に関わるベストプラクティスも大部分は同じ様に適用できそうなので非常に効率良く移行ができると感じました。</p>
<p>サポートされるパラメータや拡張は決まっている為、既存のPostgreSQLインスタンスを移行する場合や実現したい機能に必要な拡張があるかは事前に以下のドキュメントで確認することができます。</p>
<ul>
<li><a href="https://cloud.google.com/alloydb/docs/reference/database-flags" target="_blank" rel="noreferrer">Supported database flags &nbsp;|&nbsp; AlloyDB for PostgreSQL &nbsp;|&nbsp; Google Cloud</a></li>
<li><a href="https://cloud.google.com/alloydb/docs/reference/extensions" target="_blank" rel="noreferrer">Supported database extensions &nbsp;|&nbsp; AlloyDB for PostgreSQL &nbsp;|&nbsp; Google Cloud</a></li>
</ul>
<p>マイグレーションに関しては、<a href="https://cloud.google.com/database-migration" target="_blank" rel="noreferrer">Database Migration Service</a>でサポートされることになると思われます。また、異なるDBを使用しているなど複雑で支援が必要な場合では<a href="https://cloud.google.com/resources/database-migration-program" target="_blank" rel="noreferrer">Database Migration Program</a>で移行支援も受ける事ができます。</p>
<h3 id="高パフォーマンス">高パフォーマンス</h3>
<p>パフォーマンス面は大きく優位性があるとのことで、標準のPostgreSQLと比較してOLTPが4倍、OLAPでは100倍のパフォーマンスであると発表されています。</p>
<div class="TableScroll"><table>
<thead>
<tr>
<th>OLTP</th>
<th>OLAP</th>
</tr>
</thead>
<tbody>
<tr>
<td><img src="https://ik.imagekit.io/plaid/f5bcca91-4418-4b25-beb3-5d149f7f47c5/1000x1000/alloydb_4x.png" alt="alloydb_4x.png"></td>
<td><img src="https://ik.imagekit.io/plaid/26e2432e-5fec-4770-8e22-dd65f9599daf/1000x1000/alloydb_100x.png" alt="alloydb_100x.png"></td>
</tr>
</tbody>
</table></div>
<p><a href="https://www.youtube.com/watch?v=o5pKfH0Tonw" target="_blank" rel="noreferrer">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>PostgreSQLと互換性を保ちながら、内部のストレージやキャッシュシステム等は独自的なものに変更されている様です。<br>
特にストレージについては別のブログポストで解説されていますが、ストレージを分離することでストレージのスケーラビリティを向上させつつI/Oによるブロック時間を極力低減させる構造を作り、トランザクション処理の高速化やレプリケーションの低遅延などを実現している様です。<br>
<a href="https://cloud.google.com/blog/products/databases/alloydb-for-postgresql-intelligent-scalable-storage" target="_blank" rel="noreferrer">AlloyDB for PostgreSQL intelligent scalable storage | Google Cloud Blog</a></p>
<p>実際にはそれぞれのワークロードの特性やコストバランスに依るところが大きいにしても、<br>
既に運用しているPostgreSQLをそのまま置き換えることを検証する価値はあると感じます。</p>
<h3 id="columnar engine（高速なOLAP）">columnar engine（高速なOLAP）</h3>
<p><img src="https://ik.imagekit.io/plaid/e6d50050-ec77-42d4-a034-486461dd600d/1000x1000/alloydb_columnar_engine.png" alt="alloydb_columnar_engine.png"><br>
<a href="https://www.youtube.com/watch?v=o5pKfH0Tonw" target="_blank" rel="noreferrer">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>PLAIDでも最も注目し検証している機能が、この<a href="https://cloud.google.com/alloydb/docs/columnar-engine/about" target="_blank" rel="noreferrer">columnar engine</a>です。<br>
OLAPの100倍高速化、という特徴はこのcolumnar engineにより実現されています。</p>
<p>本来行指向データベースであるPostgreSQLに列指向データベースとしての特性を<strong>透過的</strong>に加えることができ、<a href="https://cloud.google.com/alloydb/docs/columnar-engine/quickstart" target="_blank" rel="noreferrer">セットアップ</a>を行うとインメモリ上でカラムデータを保持する様になり、クエリ側は特殊な記法などは無く列指向のスキャンが行えるかは内部で自動判断されます。<br>
また、完全にcolumnar engineで列指向スキャンされるカラムに対してはindexが不要になる為、削除することで負荷削減に繋がります。</p>
<p>インメモリに対してどのテーブルのどのカラムを保持するべきか、実行されたクエリに基づき判断する<a href="https://cloud.google.com/alloydb/docs/columnar-engine/quickstart#auto-populate" target="_blank" rel="noreferrer">レコメンデーション機能</a>が用意されているので、既存のデータとワークロードを移行しつつ、強く意識せずにOLAP処理を高速化するという導入の仕方も可能かと思います。（弊社では検証の特性上、<a href="https://cloud.google.com/alloydb/docs/columnar-engine/manage-content-manually" target="_blank" rel="noreferrer">手動での管理</a>で行なっていました）</p>
<p>列指向はより巨大なデータを扱うDWHで特に採用されることが多く、大量データの分析処理に適しています。<br>
つまりAlloyDBで従来の行指向データベースとしての適所であるOLTPのワークロードをカバーしつつ、<br>
列指向の特性を加えてOLAPのワークロードも同データベースでカバーできる可能性があるということです。<br>
マスターとして使用するRDBMSから主にデータ分析用途などでDWHにデータをロードするという流れは良くに行われていると思いますが、<br>
統合されたシンプルなアーキテクチャを実現しつつ同時に高速化を狙う選択肢が持てるのは魅力的です。</p>
<h3 id="柔軟で高い可用性を持った構成">柔軟で高い可用性を持った構成</h3>
<p>AlloyDBではClusterという単位毎に1つのPrimaryとオプショナルで複数のRead poolインスタンスを構成することができます。<br>
<img src="https://ik.imagekit.io/plaid/28c94b66-45b9-41c2-b3b0-91a38d0c5593/1000x1000/adb-resource-tree.png" alt="adb-resource-tree.png"><br>
<a href="https://cloud.google.com/alloydb/docs/overview#hierarchical_resource_structure" target="_blank" rel="noreferrer">Hierarchical resource structure</a> より引用</p>
<p>PrimaryはHAを選択すれば自動フェイルオーバーするStand-byが構成されます。<br>
Read poolは読み取り専用のレプリカとして使用でき、特にリソースを多く使う分析クエリはRead pool側に流すという構成を取ることで書き込み処理に影響を与えず処理を載せることができます。複数構成することができるので、例えば負荷特性の異なる機能に応じてRead poolを分け、マシンスペックやノード数、パラメータをそれぞれで調整するといったことも簡単に行えます。<br>
ただし、Read poolは非常に短時間ながらPrimaryに対してラグがある為、完全な一貫性が必要で無い機能で使用することになります。</p>
<h3 id="機械学習による自動化されたリソース管理">機械学習による自動化されたリソース管理</h3>
<p><img src="https://ik.imagekit.io/plaid/df5df673-52a6-4c10-9271-afa9a6eb150e/1000x1000/alloydb_autopilot.png" alt="alloydb_autopilot.png"><br>
<a href="https://www.youtube.com/watch?v=o5pKfH0Tonw" target="_blank" rel="noreferrer">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>詳細な仕様についてはまだ情報が無い様ですがコストやパフォーマンスに関わるDB管理の自動化が行われる機能があり、経験値と手間が必要なベーシックなチューニング作業は任せることもできそうです。</p>
<h3 id="シンプルな料金体系">シンプルな料金体系</h3>
<p><a href="https://cloud.google.com/alloydb/pricing" target="_blank" rel="noreferrer">https://cloud.google.com/alloydb/pricing</a></p>
<p>現状は非常にシンプルで、CPU・メモリ/ストレージ/NWによりテーブルが決まります。NWはEgressのみが課金です。<br>
プレビュー期間中はFair Usage Limitsに基づき無料で試すことができます。</p>
<h2 id="PLAIDで行なっていた検証と今後どの様に使っていきたいか">PLAIDで行なっていた検証と今後どの様に使っていきたいか</h2>
<p>上記の通りAlloyDBはPostgreSQLとの完全な互換性があり、すでにPostgreSQLを使用しているアプリケーションを変更すること無く移行が可能なことが特徴の一つですが、弊社では既存システムで使っている訳では無いので、分かりやすい検証事例はまだありません。</p>
<p>PLAIDでは OLTP/HTAP/OLAP 様々なデータ処理においてBigtableやSpanner、BigQueryといったGoogle Cloudのデータベースプロダクトを使い倒していますが（<a href="https://tech.plaid.co.jp/google-cloud-day-digital-2022">ご参考</a>）、<br>
その上でもcolumnar engineをはじめとしてして分析機能での活用で大きなパフォーマンス改善につながるポテンシャルを持っていると考え特にOLAPの拡張の観点を中心に検証を行なっています。</p>
<p>その為、上に挙げた様な他のGoogle Cloudのデータベースとのインテグレーション機能の追加にも強く期待しており、今後の機能拡張もウォッチしながら引き続き検証を進めていく予定ですので、また折々でご紹介できればと思います。</p>
<h2 id="最後に">最後に</h2>
<p>弊社では <a href="https://karte.io/" target="_blank" rel="noreferrer">KARTE</a> をはじめ、事業においてデータを中心におき展開しています。<br>
より大量のデータを、より早く、柔軟に処理する為に様々なデータベースを活用しており、今後もよりもっと多くのデータベースを試し導入しながら良いプロダクトを作っていきたいと考えています。<br>
データベースが好きな方にとってはとても楽しい環境だと思うので、ぜひ興味のある方は<a href="https://meet.plaid.co.jp/" target="_blank" rel="noreferrer">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects" target="_blank" rel="noreferrer">Wantedly</a> からお気軽にご連絡ください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
<script>
    /**
     * For displaying a table of contents - pass the entire document (DOM) to getTocMarkup
     */

    function getHeaderLevel(header) {
        return Number(header.nodeName.slice(-1));
    }

    function createTocMarkup(headers) {
        var prevLevel = 1;
        var output = "";

        headers.forEach(function(h) {
            var currLevel = getHeaderLevel(h);
            if (currLevel > prevLevel) {
                var ranOnce = false;
                while (currLevel > prevLevel) {
                    if (ranOnce) {
                        output += "&nbsp;";
                    }
                    output += "<ol style=\"margin-bottom:0px\"><li>";
                    prevLevel += 1;
                    ranOnce = true;
                }
            } else if (currLevel == prevLevel) {
                output += "</li><li>";
            } else if (currLevel < prevLevel) {
                while (currLevel < prevLevel) {
                    output += "</li></ol>";
                    prevLevel -= 1;
                }
                output += "<li>";
            }

            output += `<a href="#${h.id}">${h.innerText}</a>`;
        });

        if (output != "") {
            // Change 2 to the max header level you want in the TOC; in my case, H2
            while (prevLevel >= 2) {
                output += "</li></ol>";
                prevLevel -= 1;
            }
            output = `<h2 class="widget-title">目次</h2>${output}`;
        }

        return output;
    }

    function getTocMarkup(document) {
        // I was only interested in the headers within the element that had the .post-content class,
        // which is specific to the Ghost blog. If you're using this elsewhere, or are interested in
        // the entire document, delete this line and use document.querySelectorAll(...) on the next line.
        var body = document.getElementsByClassName('Article_Body_JS')[0];

        // Add or remove header tags you do (or don't) want to include in the TOC
        var headers = body.querySelectorAll('h2, h3, h4, h5, h6');

        // Change the number to 1 if you want headers no matter what.
        // Or if you want at least 3 headers before generating a TOC, change it to 3.
        if (headers.length >= 2) {
            return createTocMarkup(headers);
        } else {
            return "";
        }
    }
</script>
<script type="text/javascript">
    document.getElementById('toc').innerHTML = getTocMarkup(document);
</script>
</body></html>

5/12(日本時間)にGoogle I/Oで AlloyDB と呼ばれる新しいデータベースプロダクトがアナウンスされ、弊社のコメントもイベント内で引用して頂きました。この記事では、AlloyDBの特徴とPLAIDで今後どの様に使っていきたいかをご紹介します。

AlloyDBのPrivate previewに参加し、Google I/Oでコメントが引用されました