オンプレミス/クラウドDWHからSnowflakeに移行する顧客の目的は?
データマイグレーションの実態とポイント、Snowflakeが説明
2024年02月05日 07時00分更新
「データの移行、マイグレーションは決して簡単なことではない。昔は、移行だけで3年かかった、5年かかったという話すらあった。ただし、正しいアプローチをちゃんと取っていけば、必ずしもすごく大変というわけでもない。われわれの持っている事例では、4カ月で移行が完了した例も出てきている」(Snowflake 並木知己氏)
Snowflakeは2024年1月25日、企業におけるデータマイグレーションの実態や課題、およびマイグレーションを支援する同社のプロフェッショナルサービスに関する技術説明会を開催した。同社でプロフェッショナルサービスを担当する並木知己氏、セールスエンジニアリングを担当する井口和弘氏が説明を行った。
データ移行への「期待」はさまざま、それらを包括的に実現する必要がある
そもそも何を期待して(目的として)、企業は既存システムからのデータマイグレーションを行うのか。並木氏は、まずその点から説明を始めた。
オンプレミスシステムからSnowflakeへデータを移行する主な背景としては、「データのサイロ化」「TCO(総保有コスト)の上昇」「既存システムのEOS/EOL(サポート終了に伴うクラウド移行)」があるという。“データクラウド”であるSnowflakeに移行し、データの一元的な統合を図ることで、こうした課題を解消したいという期待だ。
他方で、最近では他社のクラウドDWHからSnowflakeにマイグレーションするケースも出てきているという。この場合、顧客が主に期待することとしては「パフォーマンスの改善」「使い勝手の良さ」「社内でのデータ共有の改善」「『Snowflakeマーケットプレイス』からのサードパーティデータの入手」といったことだという。
「オンプレミスからの移行において、POC段階で一番確認されるのはTCOの削減効果だ。移行によってどれだけ速くなるのか、どれだけ安くなるのか、どれだけ運用コストが減るのか、この3点にフォーカスが当たるケースが多い。一方で、(他社の)クラウドDWHからの移行では、パフォーマンスの改善効果を期待されるお客様が多い」(並木氏)
ちなみに顧客企業が抱く「期待」は、経営層と現場担当者でも大きく違うという。経営層はデータ活用を通じて自社の事業パフォーマンスを向上させたいと考えるが、現場担当者は「そうは言っても」TCOや生産性、使い勝手も重要だと考える。そのどちらも実現できるマイグレーションでなければならない。
データマイグレーションにより得られる効果は? 導入事例を紹介
では、実際にどのくらいの導入効果が見込めるのか。
並木氏は、あくまでも一例としながらも、データマーケティングSaaS「B→Dash」を提供するデータXの事例を紹介した。同社では、パブリッククラウド(IaaS)上にデータ基盤を構築していたが、それをSnowflakeに移行。その結果、パフォーマンス(処理時間)は平均で87%改善、ビッグデータプラットフォームのコストは平均で33%改善、そしてオペレーション人員は“ほぼゼロ”にできたという。
「パフォーマンスについて付け加えると、彼ら(B→Dash)がお客様に提供している顧客セグメントの抽出機能(データパレット)もSnowflakeで稼働しており、そのパフォーマンス向上にもダイレクトに寄与している。これまで1時間経っても抽出処理が終わらなかったものが数分で終わる、したがって抽出条件を変えながら試行錯誤もできる、これで圧倒的にサービスの満足度が高まっている」(井口氏)
さらに井口氏は、バッチ処理のパフォーマンス向上と時間短縮は、ストレートにクラウドインスタンスコストの削減にもつながると説明した。
またオペレーション負荷の軽減については、Snowflakeではデータの処理量に応じて自動的にスケールアップがなされるため、データ量を常に監視して手作業でそのオペレーションする必要がないと説明した。加えて、メンテナンス作業が大幅に削減されることもメリットとして挙げた。
「(データ基盤の)メンテナンスにはお客様も非常に苦しんでいる。いろいろなお客様に『Snowflakeに移行して何が良かったと思うか』と聞くと、実はパフォーマンスでもコストでもなく『メンテナンスが楽になった』という声が一番多い」(井口氏)
なお、マイグレーションの実施によって期待できるパフォーマンスやコストの改善度合いは、顧客の持つデータやコードによって大きく異なる。そのため、Snowflakeでは顧客にPOCの実施を推奨しており、POCのためのフリートライアルライセンスや技術支援の提供なども行っていると説明した。
「ある程度まとまった契約をいただければボリュームディスカウントも効きやすいが、Snowflakeではその前に実際に使ってみて、実感していただくということを一番大切にしている。そのために、コンサンプションベースの課金モデルを採用している」(井口氏)
移行で直面する課題、“リフト&シフト”の提案やプロジェクトの延期勧告も
実際にマイグレーションを行ううえでは、当然、さまざまな課題にも直面する。並木氏はその主な例として、「現行DWHの機能を実現できるのか」「移行後の新たな基盤をどうすれば最適に活用できるのか」「連携するシステムのソースコード(SQLなど)の変換作業とノウハウ」の3つを挙げる。こうした課題のそれぞれに対して、並木氏らはプロフェッショナルサービスを通じて、ベストプラクティスやノウハウの提供、支援といったものを行っているという。
「たとえば、現行の機能をSnowflakeでどのように実現できるのかという部分では、SnowflakeのDWHとしての特徴、さらには『Snowpark』のようなアドバンスト的な特徴についてしっかりお伝えする。また、Snowflakeを最適なパフォーマンスとコストで活用いただくための、ベストプラクティスをご案内する」(並木氏)
3つめのソースコード変換については、「SnowConvert」という自動変換ツールを用意していることを紹介した。このSnowConvertには、マイグレーションに関するSnowflakeのノウハウが詰め込まれており、単にSnowflakeで動作するだけでなく、より効率的に処理を実行できるコードへの書き換えも行われるという。
現状のSnowConvertは、Oracle Database、Teradata、SQL Serverからのマイグレーションに対応しており、今後はSpark関連のコード(Python、Java)変換にも対応する予定だとした。また将来的に、SnowConvertをSIパートナーにも提供する計画もあるという。
「最初に述べたとおり、マイグレーションの道のりは簡単なものではない。ただしそれを極力簡単にしていくための、いろいろな方法はあると考えており、それによってより短期間での移行も可能になっていることをご理解いただきたい」(並木氏)
なお、大規模な移行プロジェクトにおいては、Snowflakeへのマイグレーションとデータモデルなどの最適化を一度に行うのではなく、IaaSにおける“リフト&シフト”のような段階的な手順をとることを推奨しているという。
「(移行、最適化を)一気にやりたいというニーズをいただくこともあるが、最終的なコストやリスクを考えると、やはり一度データを“リフト”(移行のみ)して、その後に最適化を行うアプローチのほうが適性だと判断するケースが多い」(並木氏)
ちなみに、顧客企業側が前のめりに進めようとしているプロジェクトに対して、Snowflake側で状況を見て「今すぐやるべきではない」と伝えることもあるという。
「構築作業で手を動かす場面もあるので、やはりSnowflakeのエクスペリエンス(利用経験)やスキルを持つエンジニアがいなければ失敗につながる。パートナー(SIer)やインハウスにそういうエンジニアさんが豊富にいらっしゃいますかとお聞きして、全然いないようなケースでは、あらためてその段階から始めましょうとお伝えすることもある」(並木氏)