最新のデータアプリケーションを構築する３つのコツ

現在の開発環境を望ましい環境に変える方法

ビジネスインテリジェンスとアナリティクスソフトウェアの世界市場は、今後ますます拡大し、 多くの企業が、顧客に関するインサイトをリアルタイムで得られるアナリティクスソリューションへの投資を増やすと見込まれています。こうした企業の狙いは、データドリブンなインサイトで集客力、カスタマーサービス、顧客維持を強化することにあります。

データアプリケーション需要が今後も継続的に成長していく現状は、SaaSをはじめとするクラウドベースアプリケーションのプロバイダーにとって喜ばしいことです。新しいアプリケーションのプロバイダーは、営業、マーケティングの自動化、顧客関係管理といった市場の大手ベンダーを脅かし、ヘルスケア、自動車、保険、金融などの垂直市場全体を揺るがしています。

しかし多くの組織が、最適なタイミングでデータから実用的なインサイトを引き出したいと考えている一方で、その目標を実現できると考える組織は、それほど多くないのが現状です。数々の企業が、ビジネス運営の内容とスピードを向上させ、費用を抑え、スマート化を進めるために、強力な機能とリアルタイムのインサイトを求める中で、長期にわたり差別化できる価値を企業にもたらすSaaSプロバイダーには、大きな機会があります。ただし機会を生かすには、SaaSプロバイダー自身が最新のアーキテクチャを使ってアプリを開発する必要があります。顧客の期待を満たす最新のアプリケーションを提供するには、大きな障害を克服しなくてはなりません。長年依存しているレガシーアーキテクチャは、スケーラビリティ、同時実行性、性能に限界を抱えているからです。

データスタック選びに失敗すると、のちに多くの出費に見舞われ、成功のチャンスを失うことになります。このeBookでは、アーキテクチャと性能を左右する重要な課題について説明し、データアプリケーションの構築に最適なデータスタックを選ぶ3つのコツをご紹介します。

基本を最優先：アーキテクチャが重要な理由

クラウドでもオンプレミスでも、データアプリケーションで最も重要なのは、アプリケーションを支えるインフラとアーキテクチャです。アプリは最新でも、アプリを動かすインフラがレガシー環境から移植されている残念なアプリは、枚挙に暇（いとま）がありません。たとえばデータウェアハウスなどのレガシープラットフォームでディスクスペースを割り当てている状態を想像してみてください。SaaSプロバイダーは、ストレージとコンピュートノードに一定の容量を関連付けることになります。容量を増やすには、手動でノードを増やすしかありません。つまりデータを手動で再配分する作業が終わるまで、プラットフォームをシャットダウンするか、読み取り専用モードにしておかなくてはならないということです。一部のSaaSプロバイダーは、将来必要になる最大容量を推測し、今の需要量より多めのプロビジョニングで対応しようとします。ところが、この戦略では費用がかさみ、実際の使用量に見合った容量へのスケールダウンも、ほぼ不可能です。

なぜこのような制約に縛られるのでしょうか?従来のデータスタックは、クラウドの誕生よりずっと昔に考案されたものです。大規模なSaaSアプリケーションで半構造化データを扱うことなど、構築時には想定されていませんでした。主に内部ソースを使い、最初から量も種類もわかっている範囲の構造化データを扱う小規模なマシンクラスタが、設計の大前提でした。当然の帰結として、従来のデータスタックは、アプリケーションログ、ウェブアプリケーション、モバイルデバイス、ソーシャルメディア、センサーデータ、IoTデータなどの多様な外部ソースから際限なく送り込まれる今日の大規模かつスキーマレスの半構造化データには対応できていません。

残念なことに、多くのソフトウェアベンダーは、データアナリティクスアプリの開発に当たり真っ先に、先行投資なしで迅速に開発できる汎用的なアーキテクチャプランとツールを採用します。この方法では簡単に初期コストを削減できますが、本質的な技術的課題が発生してスループットが低下し、カスタマーエクスペリエンスが劣化して、顧客の不満や失望を買うことになります。最終的にSaaSプロバイダーは、最新のリアルタイムアプリケーション体験を提供するには、アーキテクチャを再構築する投資が必要だったと思い知ることになります。

次のフロンティアへ：ほぼ無限のスケーラビリティを持つ高性能SAAS

SaaSプロバイダーは、レガシーアーキテクチャの欠点を補い、コスト効率の高い方法でリアルタイムアナリティクスを実装して、迅速で信頼性が高く、顧客が実際に役立つと感じる体験を提供するために、最新のスタックに投資する必要があります。アナリティクスアプリに適した最新のデータプラットフォームでは、どのようなコア機能が必須となるでしょうか?

●リソースを切り離す：手動操作や中断が不要で、ジョブの大きさに比例してコンピュートリソースを個別にスケーリングするアプリが求められています。要素技術が互いに依存しない設計では、必要なとき即座にリソースをスケーリングできます。モジュール間の依存を絶つことで、高速で効率的な最適化が実現するため、アプリケーションは常にSLAの要件を達成できます。同じくモジュール間の独立により、ほぼ無限の同時実行性が実現するため、顧客は同じデータに対して多数のクエリを同時実行でき、競合も発生しません。さらに嬉しいことに、アプリを構成するコンポーネントがそれぞれコンパクトになり、シンプルな関係になるため、コンポーネントの変更が容易になります。

●優れた伸縮性、セルフサービス対応、無駄のない従量制料金：適切なアーキテクチャでは、アプリがワークロードの変動に応じて動的かつ自動的にリソースサイズをスケールアップまたはスケールダウンできます。最新のクラウド型アーキテクチャでは、組織が当初は最小限のリソースを用意し、必要に応じて使用量を増やすことができます。また自動スケーリング機能を使い、必要最小限かつ十分な容量のリソースを確保できます。その上アクティブなクラスタの料金しか発生しないため、組織は秒刻みで使った分の料金のみ支払えばよいことになります。

●幅広いデータタイプを一手にサポート：最新のアーキテクチャを使い、アプリで構造化データ、半構造化データ、非構造化データのすべてに対応し、顧客にデータの全体像を見せる必要があります。従来のデータスタックは、処理能力に限りがあり、メモリが不足し、データストレージコストが高額な割に、構造化データしか扱えないため、何をするにも足りないものばかりです。

●開発者向けのツールと自動化：アプリケーションには、簡単に拡張できる上、開発者がアプリケーションを再設計しなくてもサービスを「プラグイン」するだけでサービスを追加できる仕組みが必要です。従来のデータプラットフォームでは、手間のかかる作業が大量に発生していましたが、最新のスタックではAPIを経由して、データエコシステム内の別のサービスを接続するだけです。この「要素技術」を互いに独立させるアプローチで開発すると、よりすばやく成果が上がり、無駄に複雑な環境を避けることができます。

●セキュリティ：現在のセキュリティの脅威から保護し、迅速に開発できるようにするには、セキュリティをアーキテクチャ設計に組み込む必要があります。最新のスタックでは、データとアクションに対するきめ細かい役割ベースでのアクセス権限制御、クラウドの保存データの常時暗号化、事故や悪意ある攻撃によるデータ損失への自動的な保護対策を通じて、この2つのニーズに同時に対応できます。

顧客の期待に必ず応えるデータアプリを構築するコツは、次の3つです。

コツ1：最高のシナリオも考慮：成長の可能性をつぶさず柔軟性を確保して設計

今のお客様は、自社ビジネスに関するリアルタイムのアナリティクスを求めています。この要望に対応し、より訴求力のある価値提案を行うため、現行のSaaSアプリケーションにアナリティクスを組み込んでいるベンダーもあります。膨大な保有データを利用し、単独で分析機能を提供することで、新しく収益源を掘り起こせると期待するベンダーもあります。アナリティクスアプリを一から構築する場合も、既存のアプリケーションに新しい機能を追加する場合も、長期的な製品のニーズに合わせてテクノロジーを決定することが重要です。アプリのバージョンが1.0か10かは問題ではありません。現在の要件だけでなく、先を見越してテクノロジーを選定することが大切です。

●最初からスケーラビリティに対応します。拡張性のないコンポーネントを使用すると、すぐに顧客が失望し、開発努力が無駄になります。ワークロードは予測しきれず、ダウンタイムはもっての外であるため、大小さまざまなワークロードをさばき、高い性能を維持するには、必要な瞬間にコンピュートリソースの融通無碍なスケールアップ、スケールダウン、スケールアウトができる必要があります。残念なことにオープンソースのソリューションは自動スケーリング機能を持たないため、その負担はすべてダイレクトに開発チームにかかってきます。

●進化する要件を継続的に支えられる環境を整えます。開発したアプリケーションがロングセラーになった場合、顧客セグメントの変化やニーズの変化は避けられません。基盤スタックは、いずれ製品要件の重点や内容が変化しても、アプリケーションを支えきる必要があります。あとから完全な再構築が必要になったと言われ、費用を捻出するより、最初から長期的なテクノロジーニーズを考え、維持する方が、はるかに割安です。場当たり的対策を選ぶと、2回アプリを開発することになるため、貴重な開発時間が失われ、新機能を開発する余裕がなくなります。

●八方ふさがりにならないようにします。ダウンタイムのリスクを減らす意図から、マルチクラウド戦略（AWS、Azure、Googleなどの複数のクラウドプロバイダーを利用すること）を採用する企業は、少なくありません。ところがマルチクラウドを実現するには、アプリケーションの下でクラウド型アーキテクチャを実行し、異種クラウドプロバイダーで共通のコードベースを用意するほかありません。クラウドプロバイダー間に本来、互換性はないため、共通化は大変な負担になります。成長に合わせてマルチクラウド化するには、その戦略をサポートするアーキテクチャを選んでおく必要があります。つまり短期的な視点でデータスタックを選ぶと、後悔するという話です。逆に顧客ニーズが進化することを忘れず、柔軟性を重視する姿勢が大切です。

※本記事はSnowflakeから提供を受けております。