テックノート

  • DB(その他)
2021.04.30

もう一歩先のDevOpsへ!データ準備のモダナイゼーション

もう一歩先のDevOpsへ! データ準備のモダナイゼーション


本稿は、企業システムが扱うテストデータを準備するための手法を最新技術で近代化する、「データ準備のモダナイゼーション」をテーマにしています。


DataOpsとは?


「データ準備のモダナイゼーション」に欠かせないのが「DataOps」(データオプス)という考え方です。そもそも「DataOps」はガートナーが使い始めた言葉で、“「データ管理者」と「データ利用者」の間のコミュニケーションの改善、データフローの統合、自動化の改善を目的とした組織全体に関わるデータ管理手法”と定義されています。

言い換えると、人、テクノロジー、業務プロセスをうまく連携させて、迅速、自動、かつ安全にデータ管理を行い、データを必要とする人とデータを提供する人の間の「摩擦」をなくすことで企業ビジネスの発展に貢献していこうというものです。


DataOpsで摩擦がない状態へ

DataOpsで摩擦がない状態へ


ここでいう「摩擦」とは、データ提供側と利用者の間で何かが障壁となってデータがスムーズに届かないことを意味しますが、お客様からよく聞く代表的な摩擦の原因には、以下の3つが挙げられます。

1.データサイズ
ビジネスが継続して発展すれば、企業が持つデータはどんどん増えていきます。すると、データを使いたい人に届ける作業、つまり、データコピーやデータ提供自体に時間がかかり、それが摩擦の原因になります。

2.専門知識
データ提供の方法は業務やシステムによって違うため、システムや業務に精通している人でなければ作業ができません。どのような手順でデータをコピーすればよいのか、コピーに失敗したらどのような影響があるか、これらの知識がない人に作業を任せるのはリスクが高くなります。したがってデータを提供できる人が限られてしまい、それが摩擦の原因になります。

3.権限分離
データ提供者と利用者は、部門、役割、職種など業務背景や立場が異なるため、その違いが摩擦の原因になるケースがあります。多くの企業では、データ利用者が必要なデータを使うために、申請と承認のプロセスを経てデータ提供者に依頼をしなければなりませんが、業務に対する認識の違いから申請が滞ることもあります。

摩擦があると、必要なときに必要なデータをタイムリーに受け取れない、無駄な待ち時間が発生する、作業の遅延が生じるといった影響が生じますが、人、テクノロジー、業務プロセスをうまく連携させて、摩擦を排除し、必要とする人がすぐにデータを使える状態にするのがDataOpsの考え方です。

なぜDataOpsが求められるのか?


ここからはなぜDataOpsが求められるかについて、DevOpsと組み合わせながら説明します。

先ほど「データを必要とする人」を一括りにしていましたが、実際には以下の図のように様々な役割の人がいます。今回はDataOpsとDevOpsの組み合わせに焦点を当て、「データを必要とする人」を「開発者」と「テスター」に絞って話を進めます。


データを必要とする人

データを必要とする人


DevOpsでは「データ準備」ステップが抜けがち

DevOpsでの登場人物は、企業システムの開発者と運用担当者です。両者の目的はビジネスの発展という点で一致していますが、顧客や業務部門に対して新しいサービスや機能を次々とリリースすることで、ビジネスの発展に貢献したいというのが開発者の立場。一方、ビジネス継続のためにシステムの安定運用を第一に考えたいというのが運用担当者の立場です。システムを変えていきたい開発者と、安定運用をさせたい運用担当では思いが大きく食い違っていますが、この食い違いがビジネスの発展を妨げる要因の1つとなることが一般論として指摘されてきました。

そこで登場したのが、開発者と運用担当者が手を組んでビジネスの発展に向けて一丸となって取り組んでいこうというのが「DevOps」という考え方です。DevOpsの実現に重要な要素は、ツールの導入と文化の創造です。今までにないツールを導入すること、それを有効活用できるように役割分担や業務フローを改革していくこと、DevOpsではこうした準備によって業務改革を推進していきます。


DevOpsに向けたアプローチ

DevOpsに向けたアプローチ



DevOpsにおける具体的なアプローチの例を見ていきましょう。開発者と運用担当者、両者の思いを叶えるには、システムの安定運用が保証された状態を維持しながらリリース頻度を増やすことが必要です。これを実現するために、開発者が新機能のコーディングを終了した後のステップを自動化するというアプローチがあります。自動化することで人手による作業を排除し、作業ミスの削減、属人化排除、作業時間の短縮などを実現します。例えば、自動ビルドツールとしてGradleやMaven、構成管理ツールとしてAnsibleやDockerの活用、そしてUFT Oneといった自動テストツールなど、DevOpsを実現する様々なツールが提供されています。

ところが、これらの一連の流れの中で、労力と時間がかかるにも関わらず、DevOpsではあまり着目されていない部分があります。それが「テストデータ準備」のステップです。

テストデータ準備の一般的な手法とは?


お客様にテストデータの準備で利用している手法をお聞きすると、以下の流れが一般的なようです。

(1)本番データベースまたは開発用のマスターデータベースのバックアップを取得
(2)開発環境へ転送
(3)開発データベースに投入
(4)テストに進む


テストデータ準備の手法

テストデータ準備の手法


テストデータの準備は、データベース製品の標準機能で実施できるため、古くから利用されている手法ですが、DevOpsという観点では多くの課題があります。例えば、データベースのサイズが大きければそれに比例してデータ準備の時間が長くなります。これはバックアップの取得そのものにも時間がかかりますが、開発環境にバックアップファイルを転送する操作にも長時間を要することになります。また、この手法はデータベースやOSコマンドを駆使するため、専門知識が必要で、特定の作業者に業務が集中する傾向があります。さらに大きな足かせとなるのが「作業申請」です。申請して承認されてからやっと作業開始に至るのですが、それまでに数時間から数日かかるケースがあります。

また、テストデータは一度準備したら終わりではありません。例えば繰り返しテストでは、毎回テストの前提条件を合わせる必要があるため、以下の(1)から(4)までのテストデータ準備の手順を繰り返さなければなりません。


繰り返しテスト

繰り返しテスト


(1)テスト用に準備したファイルのバックアップを取得する
  (ここにはテスト前の初期状態のデータが含まれる)。
(2)バックアップを取得した後に、テストを実行する。
(3)テスト結果の取得後、追加・変更したデータを削除する。
(4)初期状態のデータを再投入する。

この手法も以前からあり、(1)から(4)の作業には多くの時間と知識が必要です。テストデータの準備にかかる時間や要員はどのぐらい必要なのかについてのアンケート結果によると、平均時間は3.5日、データ準備に要する平均人数は3.8人だそうです。これはつまり、必要なテストデータが揃うまでに 平均3.8人がかりで 3.5日かけて作業をし、その間、テストが中断してしまうということです。もちろんこれが全てのテストにあてはまるわけではありませんが、企業が多くの工数をかけているテストデータ準備はDevOpsにおいて改善の余地があるステップだということがわかります。

冒頭の「データ提供における摩擦」に当てはめてみると、DevOpsにおいてのデータ提供者は運用担当者、そしてデータを必要とする人は開発者です。DevOpsをさらに強化するためには、テストデータ準備というステップを効率化し、データ提供の摩擦を解消することで、理想とするDevOpsを実現できるのです。

DevOps+DataOpsでデータ準備のモダナイゼーションが実現

DevOpsに加えてDataOpsも取り入れるとどうなるでしょうか。次の図をご覧ください。


DataOpsの効果

DataOpsの効果


この図は、開発からテストまでの 各ステップに要する時間を表しています。各ステップの長さは開発案件によって様々ですが、DevOpsによって自動化や高速化が実現され、コーディングからシステムリリースまでの時間が大幅に短縮されます。

しかしDevOpsだけでは、テストデータの準備部分が手付かずの状態です。ここにDataOpsを取り入れることで、テストデータの準備時間が短縮され、システムリリースまでのトータル時間がさらに短縮されます。これが、本稿で紹介したい「データ準備のモダナイゼーション」です。

DataOpsを実現するテクノロジー「Delphix」


DataOpsを実現する要素は、人、テクノロジー、業務プロセスの3点だとお伝えしました。ここからはDataOps実現の要素であるテクノロジーの一つとして、アシストが取り扱う「Delphix」を紹介します。

ソースコードの自動生成や DevOps によって開発の高速化を図っても、データ提供がボトルネックであれば全体の工期短縮は実現できません。Delphixは「適切なデータを必要な時に必要な人や場所へ」がコンセプトの製品です。このコンセプトに当てはまればどんなケースでもDelphixを活用できますが、 最も多く使われているシーンは「テストデータの準備」です。

特長1:Delphixによる高速なデータ提供

Delphixでは、すでにあるデータベース環境を複製元としてデータを収集し、複製元が更新されれば同期処理によって変更分を貯めていくことができます。こうして取り込んだデータはDelphixの中に履歴として保存され、履歴の中から任意の時点のデータを選んで複製先のデータベース環境に復元できます。こうして作ったものは仮想データベースと呼ばれます。

Delphixの第1のメリットは、この仮想データベースへの複製がデータサイズに関わらず数分で完了するということです。


Delphixによるデータ提供

Delphixによるデータ提供



また、Delphix最大の特徴である、断面取得と巻き戻し機能で、高速化を実現します。例えばある繰り返しテストを行う前に、一般的な手順ではまず「(1)テスト用に準備したファイルのバックアップを取得」しましたが、Delphixでは今の状態を保存しておける「断面取得」ができます。この操作は1分もかかりません。また一般的な手順では、「(2)テストを実施」し「(3)テスト結果を取得後、追加・変更したデータを削除」し「(4)初期状態のデータを再投入」しなければなりませんでした。Delphixには「巻き戻し機能」があり、ボタンを押すだけで一瞬でテスト前の初期状態のデータに戻すことができます。この巻き戻しも5分程度で完了します。

データの複製や洗い替えも自由自在に、しかも瞬時に実現できます。例えば、複製元の最新のデータで仮想データベースを上書きしたり、複製元の任意の時点のデータから、それぞれ別の仮想データベースを作成することもできます。


任意の時点のデータを再現

任意の時点のデータを再現


上の図のように(右から1つ目の青い〇)、ある仮想データベース(仮想DB①)に含まれるデータをそのまま他の仮想データベース(仮想DB②)に共有することもできます。これにより、テスターがテスト中に見つけたバグの状況を開発担当者に共有する際に、テスト環境から開発環境に、簡単に共有することができます。この共有操作も5分程度で完了します。

特長2:テスターがセルフサービスで操作できる


従来、テストデータの準備はシステムの運用担当者(データ管理者)が行っていました。しかしDelphixでは、仮想データベースの断面取得や巻き戻し、仮想データベース間のデータ共有など、すべてテスターが自分で自由自在に行えます。


セルフサービスで操作

セルフサービスで操作


Delphixのユーザー画面は非常にシンプルで、OS やデータベースを専門としない方でもすぐに操作を習得できます。Delphixを導入した弊社のお客様からは、ほとんどレクチャーなしで操作できたという声が圧倒的です。また、 ユーザーごとに操作できる仮想データベースを分けることができるため、別のチームやプロジェクトが利用しているデータベースを勝手に巻き戻してしまった、というような誤操作を心配する必要もありません。

特長3:Delphixではストレージ容量が少なく済む


ストレージ使用量削減の効果

ストレージ使用量削減の効果


例えばDelphixを利用していない環境では、 3 TB のデータベースを5つ複製するときに、単純計算で3 TB × 5DB=15 TB のストレージを用意しておかなければなりません。一方、Delphixを利用した環境では、複製元のデータベースをDelphixに取り込んだ段階で、圧縮と重複排除が行われ、3分の1程度の領域に収まるという特徴があります。つまり、複製元のデータベースサイズが3 TBであれば、ストレージ領域は1 TB程度ですむということになります。 さらにそこから複製した仮想データベースは、元のデータベースの10分の1にも満たない ストレージ消費で賄えます。

高速処理と少ないストレージ消費を実現するDelphixの仕組み

Delphixでは、複製元のデータベース容量が増加しても、仮想データベースが必要とするストレージ容量は少ないままで済み、複製、巻き戻し・断面作成などが自由自在に高速で行えます。これは、Delphixが仮想データベースを作成する際に、その時点のデータベースを物理的にコピーするのではなく、「指定したデータの最新データはここにあります」というポインタ情報だけを生成するからなのです。


Delphixの仕組み

Delphixの仕組み


また、Delphixが仮想化するのはデータを含んだデータベースのみだということもポイントです。データベースを処理するためのメモリーやCPU、いわゆるインスタンスは、複製先のサーバのリソースを使用し、Delphixのストレージに含まれるデータベース・ファイルを複製先のサーバへネットワーク経由で提供し、複製先のサーバでインスタンスが起動するという構成です。

デモンストレーション

ここまでDelphixの特徴や仕組みを解説してきました。ここで、Delphix の操作イメージをつかんでいただくために、デモ動画を2つご覧ください。

デモ1:こんなに簡単!データベースの複製


複数のテストを並行して進めるという状況で、運用担当者が新しいテスト環境を作成する様子を紹介しています。Delphixの管理者用画面で操作していきます。

<デモのリンク>
https://youtu.be/oscyUqBeRkg

これで複製は完成です。 テスト用のアプリケーションから仮想データベースに接続できる状態になるまで非常に簡単かつ短時間で準備できることがわかります。

デモ2:3ステップで紹介!データの巻き戻し


開発者やテスターが繰り返しテストを行う際、セルフサービス画面でテスト前の状態にデータを巻き戻します。

<デモのリンク>
https://youtu.be/cgD_ooGng8A

セルフサービス画面では OS やデータベースの知識がなくても直感的に断面取得や巻き戻しできることをご理解いただけたのではないでしょうか。

APIの活用で自動化も可能

先ほどの2つのデモはブラウザからの操作でしたが、Delphixの機能はすべてAPIから呼び出すことができます。APIを活用することで、DevOpsの一連の自動化の流れの中に組み込むことができます。


APIの活用で自動化も可能

APIの活用で自動化も可能


例えば、CI ツールからテストのジョブを実行すると、構成管理ツールでテスト用の環境が作成され、テストデータはDelphixが提供します。その後自動テストツールによって自動テストが実行されます。1つ目のテスト結果が想定どおりであれば、Delphixがデータを初期状態に戻し、次の自動テストに進みます。テスト結果が想定外であれば、Delphixがその状態のデータを瞬時に保存します。その後プロジェクト管理ツールが不正なテスト結果を基にチケットを発行して開発者に連絡します。チケットを受け取った開発者は、自分の開発環境を想定外の結果となったデータを読み込み、修正作業を進めていきます。これと並行し、Delphixはテストデータを初期状態に巻き戻して自動テストツールが後続のテストを進められるようにします。これを実装すれば、例えば業務時間の終わりにジョブを実行させておき、夜間に一通りのテストを実行させて翌日には想定外の結果となった部分だけを チェックして修正するという対応が可能になります。これにより、システムリリースまでの期間を大幅に短縮できます。

クラウド上の開発環境に高品質なデータを

必要に応じて都度環境を作るというDevOps のアプローチと非常に相性が良いのがクラウドです。もちろんDelphixはクラウド上でも動かすことができます。以下のように、複製元のデータベースはデータセンターにあり、開発・テスト環境はパブリッククラウド上に構築されているような場合を想定してみます。


クラウド上の開発環境に高品質のデータを

クラウド上の開発環境に高品質のデータを


このような場合、データセンターとパブリッククラウドのそれぞれにDelphixをデプロイします。そして複製元からデータを取り込み、Delphixの機能で取り込んだデータをパブリッククラウドへレプリケーションすることが可能です。2回目以降のレプリケーションでは差分データのみを転送するため通信量は最小限ですみます。Delphix間のレプリケーションによりパブリッククラウド上に複製元データベースの履歴を配置すれば、その後はパブリッククラウドのDelphixから仮想データベースを作成して開発やテストなどでの活用が可能です。

Delphixを利用せずに上記を実現するためには、データセンターでバックアップを取得し、パブリッククラウドのサーバーへファイル転送し、その後リストアをしなければなりません。データの摩擦が生じやすい部分であるため、クラウドでの開発でもDataOpsが求められます。

事例:メトロバンク(イギリス)

メトロバンク(Metro Bank)では、ITを積極的に利用した事業展開を目指し、計画的かつ継続的な短期開発のためにDevOpsに取り組んでいました。 同時並行で進行するプロジェクトの数が増え、開発テスト環境も増えた結果、テストデータの準備がボトルネックになっていることが次第に浮き彫りになってきました。まさに開発現場におけるデータの摩擦が生じている状態です。

そこでDelphixを採用し、テストデータの巻き戻し機能により大きな成果を得ることができました。回帰テストにおけるデータのリセットに、従来の方法では全データのリセットに5日間かかっていたところ、Delphix導入後は約2時間で完了、セルフサービスで巻き戻しに対応できるようになったため、データベース管理者の対応工数が75%も削減されました。また、これらの成果により、Delphix への導入投資はわずか6週間で回収できたそうです。DataOpsへの取り組みが事業の成長に大きく貢献した事例です。

■出典:"Metro Bank acceleratesproject delivery with Delphix" (英語原文)
https://www.delphix.com/sites/default/files/2017-07/case-study-metro-bank.pdf

まとめ


DevOpsに取り組むことで、従来の開発手法に比べ、システムのリリーススピードを大幅に向上させることができますが、テスト段階で使用するデータの準備部分だけは手付かずな状態のままであることが多いのではないでしょうか。そこでレガシーなデータ準備の手法をモダナイズして、開発者やテスターに迅速にテストデータを提供するというDataOpsの考え方をご紹介しました。

本稿ではDataOpsの要素のひとつであるテクノロジーに着目し、Delphixという製品を紹介しました。Delphixを利用すれば、必要なテストデータをすぐに提供でき、提供されたデータはセルフサービスで自由に活用することができます。さらにデータ提供や断面取得・巻き戻しなどの 操作は API で呼び出すこともできるため、開発、テスト、システムリリースという一連の自動化の流れの中に組み込むことが可能です。

今回は「もう一歩先のDevOpsへ」というテーマでお話しさせていただきましたが、DevOpsへの取り組み前であっても、データ提供に時間と工数がかかるという課題をお持ちであれば、Delphixによる改善が大いに期待できます。

※アシストではDelphixの PoC サービスも提供しています。自社環境で試してみたいというお客様は是非ご連絡ください。

問い合わせ先
https://www.ashisuto.co.jp/product/category/db-virtual/delphix/contact/#tab


執筆者のご紹介

アシスト小山 雄貴

小山 雄貴
ビジネスインフラ技術本部 データベース技術統括部

2012年入社。Oracle Databaseのフィールドエンジニア部隊でシステム構築やお客様密着型の技術サポートに携わったのち、2017年からDelphix製品チームに所属。お客様の課題に合わせたDelphix活用のご案内、導入支援、サポートなど、Delphixに関するあらゆる業務を担当中。

本記事をご覧いただいている方へのご案内

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。

関連している記事

  • DB(Oracle Database)
  • DB(その他)
2019.01.28

ゼロからのリレーショナルデータベース入門

データベースに対する敷居を少しでも低くするために、初心者の方に必要なデータベースの基本から、障害対策やチューニングといった実践に即した内容までを幅広く解説していきます。

  • DB(その他)
2018.07.23

さらばダミーデータ!超高速開発を実現するテストデータ活用

膨大なデータを活用することが求められる一方で、安全に扱うための制約も増加しています。データ活用の中でもテストデータに関する課題を例に、ビジネスに変革を与えるDelphixの新しいデータ活用をご紹介します。

  • DB(その他)
2018.07.02

AIブームを支える「機械学習」~AIの現実的な始め方とは?~

AIブームは着実に広まっています。しかし先進的な事例が先行し、裏側の仕組みや現実的な取り組みについての理解が追い付いていないように見受けられます。AIを支えるディープラーニングと機械学習技術の紹介を中心に、導入までに必要な具体的なステップを見ていきます。

ページの先頭へ戻る