Tポイント分析基盤の歴史とSnowflakeへ移行した話②
記事の目的
レガシーが多いシステムをモダンアーキテクチャに移管するのは非常に労力を伴いますが、どのように移行したかの具体事例や、特に途中の労苦を語ったものは少なく、皆様の参考になればと思い、恥ずかしい話もありますが勇気をもって投稿します！
TポイントからVポイントへ2024/4/22にブランド名が変わってますが、
当時の話なので、Tポイントで記載しています
前回までの話
Vポイント分析基盤の歴史とSnowflakeへ移行した話①
次の分析基盤に向けて
2017年から3年がかかりになった、Oracle ExadataからAzure Synapse Analyticsへの移行が完了しつつある2019年。
クラウド環境が出来た事でコンピュートリソースの調達が自由になり、アナリストやサイエンティスト部門と様々な取り組みが増えていきました。
Tableauの導入や機械学習環境の構築など、僕自身もクラウド移行のPMをしている片手間で
TableauServer構築したり、機械学習用のVMを基盤と準備したり、
ある意味、苦しいプロジェクトの息抜きも兼ねてアドホックに色んな構築やら作業をしていました。
そういう色々な分析に関するサービスニーズを肌で感じる中、
AzureSynapseの同時実行の仕様や拡張するための課題もあり、移行後の環境で、さらに多様なワークロードを相乗りさせるのは難しいと感じるようになりました。
Synapseの同時実行仕様
SynapseではDWUという単位でスペックが拡張するようになっており、
このDWUに応じて同時実行スロット数が定められています。
各DWUスペックに合わせスロット数が割り振られており、弊社が運用していた10000DWUの場合、400スロットが確保されています。
一方で、1ユーザーがクエリを実行する際のスロット数の割当をリソースクラスというロールで割り当てを行います。
なので、1スロットであれば100多重までは実行可能なのですが、
このスロット数に応じてメモリサイズも決まっており、実行性能とのバランスから
・アナリスト向けにstaticsrc30を割当（スロット4個）※左から3つ目のクラス
・それ以外にセグメント配信の条件設定などショートクエリ用にstaticrc20（スロット2個）、
・大規模な集計やバッチ処理などは、staticsrc50(スロット16個)
などと全体設計として、アナリストで60多重、セグメント配信などで20多重、その他バッチなど
概ね100多重内で各処理を実行しており、上限を超える場合は実行待ちという構成にしていました。
Synapseのスペックアップによる拡張案
Syanpse自体をスペックアップさせる方法も当然ありますが、
10000DWUの上は、15000DWUとコスト1.5倍となります。
DWUを上げることでコンピュートの数が増えるので当然クエリ性能も上がるのですが、
過去の感触的に1.2~1.3倍の性能向上程度の期待でした。
またそのコンピュート内で、多様なワークロードを実行出来たとしても
ヘビークエリに引きずられる事象は容易に想像出来ます。
コスト的にもリザーブドインスタンス前提となってしまうので、
実質的に拡張後、3年間はこのアーキテクチャで運用する前提となります。
Synapseのアップデートの停滞
Gen2リリース後の機能アップデートも落ち着いてしまい、
本国の開発エンジニアからの情報も期待できるようなアップデート計画も聞かなくなりました。
性能問題などを通じてSynapseのアーキテクチャをそれなりに理解していたつもりですが、
その理解度から見た見解として相当なアップデートやアーキテクチャ変更がない限り、
多様なワークロードを実現する基盤になるのは難しいと考えるようになりました。
※Synapseはかなりの高パフォーマンスな製品で分析基盤としての採用を否定するものではありません。
またそれを満たせる可能性のある、Synapse Gen3の開発計画をMicrosoftの開発部門から伺っていました。
・その中ではコンピュートとストレージの完全な分離、より柔軟に拡縮できる構成
・マスターノードがボトルネックになるアーキテクチャの見直し
（マルチクラスタ的 これはVerticaっぽい構成）
この開発計画通りにいくのであれば、期待出来ると感じましたが、その計画の実現時期などは未定の状態でした。
今回のクラウド移行はオンプレでの拡張限界により、
弊社の基幹業務である分析業務の遂行を阻害していた状態をクラウド化により解決し、
かつDB統合とコストダウンを図る目的でした。
それ自体は難産の末に完了したものの、
今後数年間、事業を支え、ドライブさせる分析基盤を目指すときに
まだまだ出来ていないものが多く、自分の中でモヤモヤする思いが増してきました。
またこのタイミングでシニアマネージャーという特命課長？的な、部下を持たないポジションになり、自分のプロジェクトと各種案件のフォローのみという自分で仕事を作らないとただただ暇になる時期であったため、少し現場と距離を置いて色んな事を考えるための時間を取りました。
そういう中で、分析基盤のコンセプトを改めて考えようと思い、自分なりの要素を言語化していきました。
次期分析基盤のコンセプト
多様なワークロード
DBの統合とオンプレと比べた性能アップは出来ていますが、
それを活用するフェーズでは、BIや機械学習などの多様なワークロードが容易に上げられます。
それらデータ活用の中で増えてくるワークロードを同じデータソースに対し、それぞれが競合せず、実行出来るようなアーキテクチャが理想と考えるようになりました。
データの一元化
また以前のようにデータベースを目的別に分散させる方法もありましたが、
それはデータの一元化と逆行し、データマネジメントや開発効率・運用コストの観点でも避けるべきと考えていました。
従来のコスト観点でのインフラ統合に閉じず、データ統合する目的を再定義したものです。
データのデリバラブル
また事業の方向性を自分なりに解釈した時に最終的にTポイントのデータセットとコンピュートリソースをいかにスピーディかつエンジニアリング負荷なく、手配できるかが重要になってくると考えました。
また直近で実験的にデータソンを実施した際の環境構築が面倒くさすぎたこともあり、
自社に閉じず、他社（他者）とコラボレーションしたり、デジタル領域でのクリーンルームやCDPのような個人情報を保護しつつ、データを外部と連携し合うようになる世界が来た時にそれらを簡単かつセキュアに実現出来るようなアーキテクチャがあると良いなと漠然ながら考えました。
■CCC データソン（DATA DEMOCRACY DAYS）
次期基盤のキーワード
最終的にコンセプトを分かりやすい以下３つをキーワードとして決めました
・シングルソース
データの統合、一元化 オンプレのExadata移管の完遂
・マルチワークロード
多様なワークロードを相互に干渉せず、実行出来る環境
・デリバリーイージー
データのオープン化、コラボ、新規事業の環境構築、データ提供コストの削減
それ、実現出来るアーキテクチャあるの？？
Synapseと類似したRedshiftも同様の課題を生むだけと考え、漠然とBigQueryなどを考えていましたが、SPSS modelerにまだ正式対応していない事やその時点のGCPのサービスではセキュリティ基準を満たせなさそうで、
「絵に描いた餅だよなー、どうするよ、これ？とりあえず、まずはクラウド移行を完遂してから考えるかー？」といった感じでひとまず蓋をして、目の前のプロジェクトに専念していました。
snowflakeとの出会い
とはいえ、上記のモヤモヤを抱えていた2019年11月、この翌月にクラウド移行が完了する真っ最中に
アナリスト部門経由でクラスメソッドさんからSnowflakeを紹介されました。
この手の事業部門からの紹介は、外れも多いのですが、
そういう先入観が視野を狭くする事もあるので、極力話を聞くようにしています。（2回目）
実際に面談の場に行くと、snowflakeの東條社長とDBエヴァンジェリストの本橋さんが同席されており、本橋さんとは、彼の前職でお仕事をご一緒した事があり、Vertica仲間だったこともあり、その時点で信頼度が大幅にアップ（笑）
snowflakeのアーキテクチャの仕様を一から説明してもらい、
初回から深い質問を遠慮なくさせてもらい、またそれぞれにしっかりと回答をしてもらいました。
特にシングルソースとマルチワークロードの両立は相当難しいテーマと考えていましたが、
Snowflakeのアーキテクチャの説明を聞く中で
本当かよ？という疑念と マジか！という期待が両方沸き立ったのを今でも覚えています。
以下はその面談で質問した事のまとめです（2021年のSnowDayの登壇資料より）
アーキテクチャや仕様の具体的な話におよび
最終的にPoCをどのようにするかまで話が進み、あっという間に1時間の面談が終わりました。
そもそもの紹介者であるクラスメソッドさんの話す時間がなくなってしまい申し訳ない感じに。
メールベースで意見交換しながら、20年2月AWSの東京リージョンが開設される事も分かり、
予算承認などの段取りも含め、5月からPoCをやろうという話となりました。
PoC候補としては、分析ASPサービスのVerticaが、2021年後半にハードウェアのEOLなどを迎える事もあり、Synapseか別のアーキテクチャの検討タイミングを迎えていたため、次期基盤の試金石として白羽の矢が立ちました。
前回のVertica化の評価観点や移植性など検証すべき項目がほぼ再利用できる事もあり、
前倒しで4月に社内決裁を取り、5ヵ月ほどでPoCおよび本移行の費用試算まで終える段取りで開始しました。
後から聞くと、Snowflakeの日本オフィスが開設されたのは12月で、
日本オフィスが出来てもないのに採用しようとした企業はあんまりないらしく、
東條社長が弊社役員などと面談する際にも毎回言われます。
言われた役員の反応が、
「先見の明があるのか、それともやばいリスクテイカーなのか？・・」、
いつもどう返していいか分からない顔をされるので、申し訳ない気持ちになっています笑
PoCの実施
さて、snowflakeのPoCで、何を評価するのか？は各企業のその前提となる基盤の状態によって異なると思いますが、弊社では以下の前提を踏まえて評価項目を定義しました。
前提となるサービス
・社内外数百ユーザーが利用する分析ASPサービス
・バスケット分析やトライアンドリピート、時系列分析、RFM分析、クラスタ分析など
10種以上の分析メニューで商品軸、店舗軸などをUIで条件指定する分析サービス
・アプリケーションはスクラッチで入力された条件を元に自動でSQLを生成し、集計を実行
・実行結果の保存や条件の再利用や集計履歴管理など管理機能を有する
・同時実行は約30多重（アプリ側で制御）
・データ量20TB（圧縮後）
・データベースVertica
・ハードウェアHP DL380 Gen9 9台構成（＋待機9台、開発3台）CPUとメモリ増設、SSD構成
・2014年に構築しており、EOLを2021年に迎える予定
性能検証
１．集計クエリの性能検証（ヘビークエリ）
月次で定点観測している性能確認用のクエリ種があり、それをベースに以下をそれぞれ現行環境と比較
・単独実行性能
・複数同時実行性能
２．ショートクエリの性能検証
画面検索や条件設定時の単純なクエリ群を現行環境と比較
３．データロード、データ削除の時間
日次でデータメンテナンスを行っているため、その時間を現行環境と比較
４．データ洗い替え
不定期でマスタの大幅更新がある場合にデータの洗い替えを実施
現行では、企業単位で1日かけて洗い替えを行っていた
また各処理も月次稼働監視の中で処理時間などを把握しているため、
同様のデータ量を準備し、それぞれ比較を行いました。
なお、このPoCはSnowflakeとSynapseの両方で実施しました。
あと時々忘れてしまいますが、resultcacheは当然オフにして試験は実施しています笑
移植性検証
主にDMLの非互換の有無とその解消方法の検証
・関数や構文、暗黙変換の有無、可否など
地味すぎますが、javaで処理する際に整数フィールドの項目に小数点があると
暗黙変換されずにエラーとなるので、TRUNCかますとか
細かいところで言えばExadata時代の名残の無効なヒント句などがsnowflakeではエラーになったりとか。（ソース汚いのバレた）
PoCの結果
結論、snowflakeを採用となったのですが、単純な性能はSynapseが早い面もあり、甲乙つけ難い部分がありました。
プログラム改修の有無
Synapseの場合、やはりtempDBの問題がこのPoCでも検出され、それにはプログラム改修が広範囲で必要な事も分かりました。
これは結構ノックアウトに近く、評価に大きく響きました。
コスト柔軟性
Synapseのコスト試算の前提が3年リザーブドのため、実質固定。
必要な時だけ一時的にダウンタイムなしにスペックアップなどが難しい構成
Snowflake側のコスト試算はPoCの結果より、ウエアハウスサイズを決めた上で、
分析ASPの10分ごとの同時実行数をまとめ、クラスタ単位（1クラスタ6クエリ）を元に算出しました。
その結果としては、Mなら確実にコストダウン、Lでもコストダウンという試算で、
現行のスペックから見た想定サイズはLがターゲットと決めました。
利用者数が伸びれば、コストも増えますが、そのASP利用料も増える前提であれば、インフラコストを変動費化出来るメリットもありました。
※ヘビーユーザーのみスペックを上げる、その代わりにASP利用料金をUPするといった柔軟なプライシングも技術的には可能（結局やらなかったけど）
ショートクエリの速度
Synapseは元々ショートクエリに遅い傾向がありました。クエリそのものよりも構文解析に時間がかかる。Synapse全般でメタ情報の取得が他のDBに比べ、若干遅い事が起因している気がします。
何度か改善されてきましたが、なかなか根本解消される事はありませんでした。
Snowflakeではそこは問題なく性能が出ていました。ちなみにVerticaはさらに速いのですが、体感できるほどの劣化はないので問題ないと判断
多重処理時の性能比較
※赤セルはVerticaよりも遅いクエリ
現行構成スペックとコスト面を元に想定サイズは
Synapseの5000,6000,7500DWUとsnowflakeのM,L,XLサイズを想定
真ん中が一番の候補で、一番上のサイズは拡張時の期待値を把握するため
Synapseの6000DWUは一部snowflakeよりも速いものはあるが、現行よりも大幅に悪化もあり
snowflakeのLサイズでは1クエリを除き、現行Vertica同等以上の性能
遅延しているクエリは現行2分弱が5分ほどとなっていましたが、
クエリを確認した結果、クラスタが拡張されているが、空いたクラスタではなく、混み合ったクラスタで運悪く実行されていた事が判明
オートスケールであってもセッション単位でクラスタへ振り分けしているので、
重たいクエリが集中するケースもあり得り、負荷分散が万能な訳ではない事も分かりました。
（2020年当時なので今はもっと高度なアルゴリズムで振り分けしているかも？？）
snowflakeの採用と社内調整
上記の性能比較や移植性などの評価を元にいくつか価格相談なども挟みつつ、
snowflakeを採用する事に決めました。
CCCMKの立場でSnowflakeは採用すれば、最短で発注できるのですが、
いずれグループ全体で利用する可能性を考えて、遠回りとなりますが
CCCとして契約し、MKはそのグループ企業として利用するという建付けとし、CCC側で本契約に向けた準備をしてもらいました。この辺り、毎回ホールディングス側に面倒をかけていますが、主旨を理解してもらえるのは感謝です。
（実際この後、各社で段階的に利用が進む事になりました。）
並行してセキュリティ周りの確認を実施し、大きな課題なくクリア
その後、全体の移行計画と開発費用の見積やSnowflakeの最終的なコスト試算も完了し、
EOLを迎えるシステムの新インフラ構築に当たっての新たなアーキテクチャ採用という主旨で
20年12月に投資計画を上程。
EOLに合わせた投資、システム部門としての技術チャレンジ、PoCで事前評価済という事もあり、全体的に異論なく、snowflake移行の投資承認は無事に得る事が出来ました。
とはいえ、Synapse移行で迷惑をかけた立場でもあり、
それでもチャレンジしようとしている自分を信じて、また任せてもらえた事に感謝です。
移行計画の開始
移行プロジェクトは、21年1月開発着手、5月リリース（実質4ヵ月）の計画でしたが、
事前に非互換対応などを精査し、プログラム変換もそれぞれボリュームが見えているため、
またVertica移行の計画をなぞる形で設計、製造、単体、結合と順調に推移、
途中でPoC時に検出出来なかった非互換パターンなども吸収しつつ、最終的な性能試験を残すのみとなりました。
性能試験は企業文化によって考え方が変わる部分もあると思いますが、
分析関連の開発では概ね以下のようなステップで試験を実施していました。
1.単体性能試験
クエリを1つずつ実行し、処理時間を比較
2.複合性能試験
集計系のクエリにより一定負荷状態を作り、画面検索などワークロードを同時実行
特にショートクエリや周辺機能側の処理時間を計測
3.複数同時実行試験
本番相当の軽中重クエリを混在して実行して、全体的な性能を確認
一定時間負荷をかけ続ける事で検出出来るDB不安定やパフォーマンス劣化の検出
4.最大値試験
項目長の最大値や集計値の最大値での集計結果が正しく出力されるか
Where句に指定する件数など、データベースごとの暗黙的な内部上限値の確認
これらを順番に実施していくのですが、事前にPoCをしていても不安はよぎるもので、
開発ベンダーのPMには「性能試験は全部完了せずとも、1の速報を、現状通りor速いor遅い だけ教えてくれ」とお願いしました。
性能試験結果の如何
試験実施は1週間ほどかけて実施しますが、初日の単体性能試験が終わった段階でPMから速報を頂きました。
Mサイズの実施結果：現行より若干劣化
Lサイズの実施結果：一部劣化があるが、全体として現行の1.7倍高速
上記はPoCとほぼ同じ結果で、その後の試験も、PoC時の単体試験通りとなり、ひとまず安心しました。
複合性能試験の実施
次に画面系を交えた複合性能試験を実施しました。
ここで画面系のクエリの速度が大幅に悪化する事象が検出されました。
クエリのプロファイルを確認すると「初期化」に大きな時間を要している事が分かりました。
snowflakeのソリューションアーキテクトの松下さんなども交えて、状態を分析し、
クラスタの負荷により、ショートクエリが待機していると判断しました。
オートスケールでこのような事象が起きるのか？と疑問を抱きましたが、
オプティマイザはスケールするほどではないと判断しているが実態の負荷により待ちが生じているとのこと。
解決策としては画面検索系のウェアハウスを分けるのが良いとアドバイスをいただき、
実際のワークロードを分類し、
集計系Lサイズ、画面系Sサイズ、ロード系Sサイズの3つに分割し、
各アプリケーションが実行するクエリのウェアハウスの指定も制御してもらいました。
その後、改めて再試験を行い、画面クエリの滞留はなくなり、
ワークロードに合わせてウェアハウスを分けるというSnowflakeのアーキテクチャ通りの対応で解消しました。
ちなみに作業用のウェアハウスをXSで用意しており、
基本的に単純な調査や確認であれば、それを使うように推奨しています。
最大値試験
概ね問題なく試験が完了しましたが、1件だけ非互換が検出されました。
一定件数以上の条件設定時に処理が必ずスタックしてしまい、
調査をした結果、SnowflakeのIn句の上限値が16,384件という事が分かりました。
ドキュメントにちゃんと書いてあり、調査やPoCでのチェック漏れでした。
分析ユーザーが稀に数万件のレコードを指定するケースがあり、
画面での選択や入力値を元に動的にSQLを生成するため、ワークテーブルに入れるなどの処理ステップを増やす事は難しく、
最終的に10,000件単位でIn句を分割して、結合するようにロジックを追加しました。
ちなみに
・OracleはIN句に制限があるので、OR句で大量指定を実装
・VerticaはOrに上限があり、In句無制限だったので、In句に変更改修
→Verticaのドキュメント上の記載がなかったので、その後記載されるように
・SnowflakeはIN句に制限があったので、In句の分割ロジックを追加改修
などなど、データベース言語ごとの制約で毎度見直している箇所だと気付きました笑
性能試験の最終結果
全体的にPoC段階から本番同等の試験をしてきたこともあり、
概ね想定通り、このフェーズでしか発見出来ない不具合はいくつかありましたが、全て解消済
社内でのリリース準備報告などを行い、利用ユーザーへシステムメンテナンスの案内を行い、
予定通り5月にリリースを実施する事となりました。
リリース初動
リリースに辺り、何等か問題が生じてもクエリが滞留しないように各ウェアハウスのミニマムクラスタ数は2台に増やしておきました。
また事前にリリース日前週の、本番の分析メニュー別のクエリ実行時間を集計しておき、
当日の同時刻の処理時間比較を出来るようにし、
後はリリース後の実際の利用状況をいくつかの監視タイミングで集計し、比較評価を行いました。
性能面としては現行同等かそれ以上となっており、問題なしと判断し、
ミニマムクラスタ数は1台に戻し、初動確認を完了しました。
リリース後の画面検索の遅延問題
リリースを週末に行った事もあり、翌週の初動より最終的な本番確認でしたが、
ここで画面の検索が従来よりも遅いというユーザーからの問い合わせがサポート窓口に入ってきました。
ただ集計用と画面用のウエアハウスは分けており、それぞれのクラスタも特にスケールしている状況でもなく、なぜ遅くなっているのかの原因調査は難航しました。
社内でも再現試験を行いましたが、なかなか再現せず、詳細な状態を確認していく中で、
問い合わせユーザー自身の操作ではなく、一定の条件下で発生する事が分かりました。
ロック待機の発覚
結論、データ更新によるロック待機が発生していました。
分析ASPサービスでは、ユーザーが集計リクエストを投げ、集計が完了するまで以下の5つのサイクルでデータの更新を行います。
上記のサイクルのうち、4の処理の集計結果テーブルへの書込は1件ずつInsertしていましたが、
この処理時間がVerticaに比べ、Snowflakeが大幅に遅い事が分かりました。
検証時に最大値の試験は実施していましたが、主に条件指定部分を観点としており、
結果テーブルへの書込件数の大量パターンは試験出来ておらず、見逃しがありました。
上記の書込が遅い事により、同じ更新処理時に一括で更新している集計ステータスTBLがテーブルロックされたままとなっており、
そのテーブルロックの間、他のユーザーの1や4の処理がロック解除待ちになることで結果として画面の更新が待ち状態となり、画面の挙動が遅いというクレームにつながっていました。
Vertica時代は書込が圧倒的に速く、このロック事象が表面化しなかっただけで潜在的な不具合でした。
上記の事象を把握後、以下2つを対策として実施しました。
①4の集計結果TBLの書込と集計ステータスTBLのトランザクションを分離
②集計結果TBLの書込をbulkInsertに変更
ただ、各分析メニュー単位で結果TBLの書込内容が異なるため、
個別に方式を見直したプログラム修正をしていく必要があり、
それなりに工数が必要な対応でしたが、発生から既に1週間以上経過していたこともあり、
本事象の発生頻度が高いメニューより優先的に実施し、段階的に緩和させていく事を判断しました。
一番発生頻度の高い集計メニューを先行してプログラム修正とテストを実施し、緊急リリースを行い、その日に画面の応答レスポンスをトレースした結果、
明らかな改善が見られたため、この改善を全メニューに順次実施をしていきました。
最終的にリリース後に生じた本事象は、
原因特定に10日間、一つ目の改善までに5日、最終的な全メニュー対応まで10日とほぼ1ヵ月ほど要しましたが、本事象が解消後、クレーム等はなくなり、安定してサービスを提供出来るようになりました。
ウェアハウス等を分けてワークロードを分離しているのに
テーブルロックで異なるワークロードに影響を与えてしまったというお粗末な結果で
今となっては笑い話ですが、当時は原因特定がなかなか出来ず、相当頭を抱えた事象でした。
最終的に分析ASPサービスのSnowflake化はリリース初動の課題をクリアし、
以降安定してサービスを提供出来ており、プロジェクトの完了を報告しました。
snowflakeの社内浸透
分析ASPの移行と並行して、snowflakeアカウント内にアナリスト部門用のDBを作成し、
Tableauを使った社内・社外のBIサービスのインフラとして先行利用を開始してもらいました。
Synapseの際は、性能課題の解決策として、”システム部門主導”で移行を進めた事もあり、
アナリスト部門の理解や協力体制の構築が難しかった反省点もあり、
今回はまず慣れ親しんでもらう、浸透作戦を取りました。
アナリスト部門としては、ある意味、自分たちが自由に使えるデータベースであり、
洗練されたUIやパフォーマンスや最新のモダンアーキテクチャに触れる機会も含め、
非常に関心高く、利用ユーザーは増えていきました。
またその中で、全部snowflakeになると業務効率上がるよね、モダン化どんどんしていきたいと
分析系メンバーの中でもsnowflake化への期待が醸成されてきました。
分析DBのsnowflake化に向けて
今回の分析ASPは試金石で、本丸はSynapseであり、まだ残っているオンプレのExadata1台です。
そのインフラ更改時期を意識して、可能な限り逆算で計画を立てました。
まずSynapseについては3年リザーブドの契約があり、
Synapseの10000DWUのうち、6000DWUは19年6月契約22年5月終了、4000DWUは19年12月契約22年11月終了
またオンプレ基幹DBも18年に構築したExadataは2025年にEOLを迎える状態でした。
上記を踏まえ、逆算スケジュールとしては
2024年中に基幹DB（Exadata)）をsnowflake化する（EOLより少し前に）
2023年中に分析DB（Synapse）をsnowflake化し、基幹DBの統合先を用意しておく
そのためには
2022年中にExadata、SynapseからSnowflakeへの移行可否を評価しておく
その前段として
2021年に分析ASPで実績作りをしていく（完了）
Synapseのリザーブドは、
6000DWU分は22年6月より3年RIで買うが4000DWU分は22年12月からは1年RIとし、
割引率が悪化する分の費用増や中途解約金などを22年、23年度の予算で考慮し、
それでもSnowflake化＆DB統合によるコストダウンや性能向上、運用コスト削減などが上回るかをシミュレーションしていきました。
分析ASPのsnowflakeコストから分析DBや基幹DBのコスト予測をしつつ、
オンプレの基幹DBを単コンでExadataを買い直すコストや複数のDBが散在する事による重複コストに比べ、リプレイスコストに掛かる費用とsnowflakeコストを比較しても、かなり良いコスト削減効果が期待出来ると判断しました。
プロジェクトはどんな会社であれば、苦しい事が多いのですが、
僕の場合、幸いにも自分で言い出した、やりだした事であることが多く、
今回もプロジェクトが成功し、社内の様々な部門が喜んでくれると思い、
プロジェクト計画をまとめ上げていきました。
snowflake先行導入時代（2020年-2021年）
さて、ここから分析DB＆基幹DBのsnowflake統合という本題にようやく入っていきます。
その辺りの話は次の記事で。（本人も後何回で終わるか分かってない）
Discussion