DataOpsを実践する7つのプラクティス

DataOpsを実践するうえで、どの領域であっても適用される具体的な7つのプラクティスがあります。

データを運用するチームと開発するチームとが上手く連携するために、どういったことに注意しなければならないのでしょうか。以下では、DataOpsそのものの定義やDataOpsの背景であるアジャイル開発にも触れつつ、DataOpsの実践的なノウハウについて紹介していきたいと思います。

なお、下記記事については以下の書籍を参考元とし執筆を行っております。

(参考元: Getting DataOps Right Andy Palmer, Michael Stonebraker, Nik Bates-Haus, Liam Cleary, Mark Marinelli Published by O’Reilly Media, Inc.”DataOps as a Discipline”)

目次

DataOpsとはなにか

DataOpsは、膨大な数の企業データソースから膨大な数の企業データ消費者に、本番データを迅速、反復、確実に提供することを可能にする、人・プロセス・ツール・サービスをつなげる方法論です。

DataOpsの必要性は、過去10年間でデータの消費量が劇的に変化したことに起因しています。インターネット・アプリケーションがアプリケーションそのものの使いやすさ、可用性、応答性に対するユーザーの期待を高めたように、Google Knowledge PanelやWikipediaなどは、データの使いやすさ、可用性、新鮮さに対するユーザーの期待を劇的に高めています。

さらに、非常に使いやすいセルフサービスのデータ作成・可視化ツールへのアクセスが増えたことで、公式チャネルが期待に応えられない場合、企業内の多くのユーザーが自分でデータを作成する準備ができ、利用できるようになりました。

これらの変化が相まって、過去にデータを提供するために使用された、コストがかかり、遅延に悩まされ、不透明なオペレーションを継続することは、もはや受け入れられない環境を作り出しているのです。

DevOpsから手がかりを得て、DataOpsはデータの作成とデリバリーを単一のアジャイルなプラクティスにまとめ、特定のビジネス機能を直接サポートすることを目指します。最終的な目標は、刻々と変化する組織の要求に対応する高品質なデータを、コスト効率よくタイムリーに提供することです。

DataOpsの7つのプラクティスを理解する

データの運用チームの役割は、開発チームが製品やサービスのコーディング、構築、テスト、パッケージ化、リリース、設定、配備、監視、管理、フィードバック収集に使用するアプリケーション、サービス、その他のインフラを提供することです。

このように、運用チームは、必然的に他分野を渡る形態となります。このような広範な領域にもかかわらず、これらすべての領域に適用される具体的なプラクティスが存在します。

DataOpsのプラクティスについてですが、以下7点が挙げられます。

・アジャイルの適用

・顧客チームとの「統合」

・すべてコードで実装

・ソフトウェア・エンジニアリングのベストプラクティスの適用

・複数の環境を維持

・ツールチェーンの統合

・すべてをテストする

以下、これらのプラクティスについて、個々に説明してきます

アジャイルの適用

DataOpsのチームが他のアジャイルチームを効果的にサポートするためには、短い納期と変化への対応力(これらの要件に付随するあらゆるもの)が必須となります。

顧客チームとの「統合」

DataOpsチームには、DataOpsチームを支援するエンジニアチームとしての顧客が社内にいるため、日常的なやりとりが容易にできるという利点があります。少なくとも日次にフィードバックを収集することもあります。DataOpsとデータエンジニアリングが同一の場所で仕事をすることが可能であれば、より望ましいです。

すべてコードで実装

これは、ホスト設定、ネットワーク設定、自動化、テスト結果の収集と公開、サービスのインストールと起動、エラー処理等を意味します。すべてがコード化されている必要があります。

ソフトウェア・エンジニアリングのベストプラクティスの適用

IaC(Infrastructure as Code:サーバーなどのシステムインフラの構築を、コードを用いて行うこと)の最大の価値は、そのコードが、私たちがソフトウェア工学で蓄積してきた数十年の知恵を使って開発されたときに達成されます。つまり、ブランチ(分岐をして開発を行うこと)やマージ(他者の開発した変更内容を取り込むこと)を含むバージョン管理、あらゆるものの自動回帰テスト、明確なコード設計とファクタリング(要素の分解)、明確なコメント、等を指します。

複数の環境を維持

開発環境、受け入れテスト環境、本番環境は別々にします。本番環境でのテストや、開発環境からの本番運用は金輪際行わないようにしましょう。DataOpsの本番環境の中には、データエンジニアの開発環境もあり、もう1つはデータエンジニアの本番環境であることに注意してください。DataOpsの開発環境は、DataOpsチームが新機能を開発するためのものです。

ツールチェーンの統合

データ運用の領域が異なれば、必要なツールの集合体も異なります。これを、「ツールチェーン」と呼びます。チームが効率的に活動するためには、これらのツールチェーンが一緒に機能する必要があります。データ移行エンジンとバージョン管理は一緒に作動する必要があります。ホストの設定とモニタリングは一緒に作動する必要があります。複数の環境を維持することになりますが、それぞれの環境の中で、すべてが連動する必要があるのです。

すべてをテストする

品質テストに合格していないデータは、決して展開をしてはなりません。リグレッションテスト(機能・非機能テストを再実行し、以前に開発・テストしたソフトウェアが変更・修正後も動作することを確認するテスト)に合格していないサービスを展開することはありません。自動化されたテストでは、本番環境に入るかなり前に問題が早期に発見されるという確信を持ちながら、迅速に変更を加えることができます。

これらの7つのプラクティスにより、小規模な運用チームがデータエンジニアリングチームと緊密に連携し、アプリケーションと分析を促進する高品質なデータをタイムリーに提供することが可能になります。

まとめ

DataOpsは、DevOpsを踏まえた高度なアプローチが必須となります。このアプローチを実践する上で、重要となる知恵や経験則を紹介しました。中には「そんな当たり前なこと」と思われる箇所もあるかもしれませんが、こういった当たり前なことこそ、DataOpsのアプローチを成功させるのに重要な要素となってきます。

弊社はDevOpsをインフラ最適化として適用する「SRE」について多くの実績を持ち、DevOpsならびにDataOpsにも精通しております。ぜひご相談ください。

ブログ一覧へ戻る