データ分析基盤アーキテクチャの変更の枠組み
分析屋の下滝です。
この記事では、データ分析基盤のアーキテクチャを変更していくための枠組みを紹介します。
企業の競争力を決めるデータ分析基盤
現代の企業活動において、顧客体験の向上や新たなデジタルサービスを構築していくために、データの活用は避けられなくなってきています。そのためには、データを蓄積するためのシステムが必要です。データを収集し、統合し、蓄積し、可視化し、分析するためのデータ分析基盤のシステムです。
顧客との接点やチャネルの増加・複雑化にともなってデータの種類や量が増えていく中で、どのようにしてデータ分析基盤のアーキテクチャを最適化していくのかは、企業の競争力を決める重要な意思決定となりえます。実際、データ分析基盤のユーザーに良い体験を提供できるかどうかが、企業・組織におけるデータ活用の程度を決める要因となります[3]。
しかしながら、当初は最適なアーキテクチャであったとしても、将来も最適とは限りません。理由の一つには、既存のアーキテクチャにおける問題を解決する、新たな技術やコンセプトが出現するためです。アーキテクチャ実装のための技術やその設計の型（パターン）が、どのくらいの速度で発生するのかは、最適化のための活動の速度に影響します。
歴史的には、データ分析基盤のアーキテクチャの発展は、どのようなものだったのでしょうか。Armbrust[1]らによれば、初期のアーキテクチャ、現在のアーキテクチャ、次世代のアーキテクチャとして、アーキテクチャの発展が捉えられています（図１）。
１．データウェアハウス：1980年代に登場（図左）
２．データレイク：2010年に登場（図中央）
３．データレイクハウス：2020年に登場（図右）
他にも近年さまざまなアーキテクチャパターンが提案されています[2]。
各パターンに関して、提唱されたときの資料は以下となります。
データレイク
lambda architecture
Kappa architecture
scaled architecture
第2版が出ています。
data mesh
その後の書籍は以下。
Live Data Stack[2]
課題
アーキテクチャパターンが出現していく傾向は、今後も続くと考えられます。このことは、アーキテクチャを設計するにあたっての選択肢が増えることを意味します。
課題は、企業として既存のアーキテクチャをどのアーキテクチャに到達するようにいつ変更させていけばいいのかの意思決定が迫られることにあります。
新たなアーキテクチャパターンは、既存のパターンでは解決できない問題を解決する動機をもとに作られます。したがって、企業は、以下2つのケースで競争力を失う可能性があります。
・既存のパターンに基づくアーキテクチャが、要求の変化に徐々に耐えられなくなり限界を迎え、競争力を失う。
・競合企業が自社より速く、従来のアーキテクチャから新たなアーキテクチャに移行することで、競争力を失う。
アーキテクチャをどのタイミングで変更するのかによって、大きく２つの変更方針が考えられます。
・問題の発生を起点に変更する：要求の変化に対応するにつれて、アーキテクチャに何らかの問題が発生しているときに変更します。問題とは、たとえば、クエリが遅い、コストが増加している等です。
・機会の発生を起点に変更する：アーキテクチャに問題は発生していないが、アーキテクチャの選択肢が増えた際には、そのアーキテクチャに到達するように変化させることで特定の目的を達成します。たとえば、クエリ速度を速くする、コストを削減するといった目的です。
ここまでは、あるアーキテクチャパターンから別のパターンへの変更に焦点を当ててきました。それよりも小さな変更も考えられます。アーキテクチャを構成する要素を置き換えるような変更です。この場合でも同様の課題が発生します。つまり、設計上の選択肢が増えることとそれに伴う既存の決定の変更です。
問題の発生を起点とする変更の事例
本節では、問題を起点に変更したと考えられる、２つの企業事例を見てみます。
アーキテクチャパターンの変更
note株式会社では、データレイクのアーキテクチャから、クラウドデータウェアハウスを用いたアーキテクチャ（snowflake）に移行した事例が紹介されています[3]。
同社が、snowflakeに移行したのは、次のような問題が発生していたためです[3]（抜粋）。
・レコード数が増え、S3のファイルが増えるとともにAthenaのタイムアウトが発生するようになった。
・データ分析の要望は増えていくが、インフラの制限により、実現できることに限りが出てきた。
・タイムアウトの回避のためデータのETLを行ったが、アーキテクチャが複雑化してしまい、開発の難易度が上がり、増える要望を消化できなくなった。
このような問題を解決するために、クラウドデータウェアハウスのアーキテクチャへの移行が行われました。移行の結果として以下が得られました。
・分析業務の効率が大幅アップした
・今まで不可能だった規模の分析が可能になった
・データ活用への興味や関心が向上した
アーキテクチャ要素の変更
REVISIO株式会社は、データウェアハウスの要素の変更として、Amazon Redshiftからsnowflakeへの移行を行いました。同社が、snowflakeに移行したのは、次のような問題が発生していたためです[4]。
・ビジネス拡大に伴い、 データ量・ユーザー・ワークロードが増加した結果、処理速度と安定性が低下した。
・それをカバーするためにスケールアップしたが、コストアップとなった。
・クラスター管理やパフォーマンス・チューニングの運用負荷が発生した。社内のエンジニアがうまくコントロールできていなかったため。
移行の結果としては、高速化、安定化、コストダウンの目的が達成できました。
機会の発生を起点とする変更の枠組み
機会の発生に基づいてアーキテクチャが最適になるように変更し続けるために、どのような組織的な活動が必要となるでしょうか。本節では素朴な枠組みを考えました。まず、設計とは何かという観点から枠組みの構成要素を特定します。
設計プロセスとは意思決定の一種だと考えられます。意思決定とは、選択肢からの選択です。
設計プロセスの結果としての設計は、選択肢から選ばれた決定の集まりだと解釈できます。
アーキテクチャの設計もまた、特定の粒度での決定の集まりと見なせます。たとえば、どのアーキテクチャパターンを選択するのか、オンプレミスとクラウドプラットフォームのどちらで構築するのか、どのクラウドプラットフォームを選択するのか、データウェアハウスのためのどのデータベースを選択するのかといった選択などです。
なお、通常、選択肢がすべて提示されているわけではないため、可能な新たな選択肢自体を探すことが設計プロセスの一部ともなります。
設計の変更とは、既存の決定（の集合）を変更することです。たとえば、事例でみたように、データウェアハウスの要素の変更です。
設計は、特定の要求（要件）を満たすために行われます。設計は、要求を満たしているかどうか評価されます。評価の結果、設計の変更が必要であることや望ましいことが判明します。たとえばコストやクエリの速度という品質での評価です。
設計の機会とは、新たな技術の出現や設計上のコンセプトの出現により、特定の品質や特性の観点から、既存の設計を改善できる選択肢が増えたことを意味します。たとえば、データレイクハウスといった新たなアーキテクチャパターンの出現は、選択肢が増えたことを意味します。
以上をもとにして、アーキテクチャの観点からの、枠組みの基本的な構成要素（プロセスの出力結果）は以下となります。
・アーキテクチャ設計（意思決定結果の集合）
・アーキテクチャへの要求
・アーキテクチャの評価結果
・アーキテクチャ設計上の選択肢の集合
設計の機会に基づく変更を行うために、上記の構成要素をもとにした活動（プロセス）には、次のようなものが考えられます。
アーキテクチャの評価
これは、現状のアーキテクチャの評価を行い、最適かどうかを確認します。クエリの速度等の評価項目を定義した上で評価を行います。
構成要素の「アーキテクチャの評価結果」を出力するプロセスにあたります。
アーキテクチャの変更
これは、現状のアーキテクチャを、よりよいアーキテクチャに向けて変更することを意味します。アーキテクチャ要素を変更するだけのこともあれば、アーキテクチャパターンの変更となることもあります。
構成要素の「アーキテクチャの設計」を出力するプロセスにあたります。
クラウドプラットフォームでの各サービスのアーキテクチャ機能の収集
これは、特定のプラットフォームでの選択肢の収集です。たとえば、特定のデータウェアハウスを採用したとして、そのデータウェアハウスと連携する新たな機能の出現により、細かな最適化の機会が生まれます。
構成要素の「アーキテクチャ設計上の選択肢の集合」を出力するプロセスにあたります。
データレイクハウスなど、新たなアーキテクチャパターンの収集
これは、アーキテクチャパターンレベルで、設計上の選択肢を集めることを意味します。
構成要素の「アーキテクチャ設計上の選択肢の集合」を出力するプロセスにあたります。
国内/海外のアーキテクチャ事例の収集
これは、他社の事例をもとに設計上の選択肢を集めることを意味します。自社が今後抱えるかもしれない問題に、他社がすでに問題に直面しており、解決しているかもしれません。解決策がパターンとして整理されていなくとも、選択肢として参考になります。
構成要素の「アーキテクチャ設計上の選択肢の集合」を出力するプロセスにあたります。
足りないアーキテクチャ要素の開発
これは、評価により明らかになった問題に対して、既存の存在する解決策が不十分だと判明した場合に、新たなアーキテクチャ要素を開発するプロセスです。
構成要素の「アーキテクチャ設計上の選択肢の集合」を出力するプロセスにあたります。
アーキテクチャと関わるユーザーからの要求の吸い上げ
データ分析基盤に関わるユーザーの視点から、アーキテクチャへの要求が何かを特定します。今は発生しなくとも、将来発生するかもしれない要求を検討することも含まれます。特定できた要求によっては、既存のアーキテクチャに当てはめて評価することで、将来の問題点が明らかになるかもしれません。場合によっては、新たなアーキテクチャパターンを生み出すことに繋がることも考えられます。
構成要素の「アーキテクチャへの要求」を出力するプロセスにあたります。
まとめ
データ分析基盤はビジネスの競争力を決める要因の一つとなりえます。新たな技術やコンセプトによるアーキテクチャ上の選択肢の出現を機会とみなしてアーキテクチャを変更していくことは、企業にとっての課題となります。本記事では、データ分析基盤を変更していく上での素朴な枠組みを紹介しました。
参考
[1] Armbrust, M. et al. Lakehouse: A New Generation of Open Platforms that Unify DataWarehousing and Advanced Analytics, 2020 (PDF)
[2] Fundamentals of Data Engineering: Plan and Build Robust Data Systems, 2022
[3] Snowflakeがもたらしたnoteのデータ分析の進化. DATA CLOUD WORLD TOUR JAPAN 講演資料, 2022
[4] 7年使ったRedshiftから6ヶ月かけてSnowflakeへ移行した話〜手の内全部お見せします〜, Snowday Japan 2023 講演資料, 2023
株式会社分析屋について
ホームページはこちら。
noteでの会社紹介記事はこちら。
【データ分析で日本を豊かに】
分析屋はシステム分野・ライフサイエンス分野・マーケティング分野の知見を生かし、多種多様な分野の企業様のデータ分析のご支援をさせていただいております。 「あなたの問題解決をする」をモットーに、お客様の抱える課題にあわせた解析・分析手法を用いて、問題解決へのお手伝いをいたします！
【マーケティング】
マーケティング戦略上の目的に向けて、各種のデータ統合及び加工ならびにPDCAサイクル運用全般を支援や高度なデータ分析技術により複雑な課題解決に向けての分析サービスを提供いたします。
【システム】
アプリケーション開発やデータベース構築、WEBサイト構築、運用保守業務などお客様の問題やご要望に沿ってご支援いたします。
【ライフサイエンス】
機械学習や各種アルゴリズムなどの解析アルゴリズム開発サービスを提供いたします。過去には医療系のバイタルデータを扱った解析が主でしたが、今後はそれらで培った経験・技術を工業など他の分野の企業様の問題解決にも役立てていく方針です。
【SES】
SESサービスも行っております。