Sabin.ioのプリンシパル・コンサルタントであるSimon Sabin氏は、先日のWinOps 2017カンファレンスで、継続的デプロイメントモデルにデータベース変更を統合する方法について講演を行なった。複数のサーバないしアプリケーションでデータベースを共有する場合に重要なのは、データベース所有者の観点で見たデータベースをAPIとして扱うことだ。
Sabin氏は、ビューやトリガ、ストアドプロシージャといった機構を使用することで、アプリケーションのデータ操作に対して後方互換性を確保しながらデータベースの内部構造を変更することが可能になる、と提案した。例として氏が紹介したのは、クレジットカード番号テーブルのプレーンテキストから暗号化テキストへの移行である。次図に示すように、トリガによって実際のテーブルを暗号化および復号化することにより、アプリケーションからは依然として、クエリによって番号をプレーンテキストとして取得することができる。
データベースがアプリケーションとの暗黙の契約/インターフェースを尊重するためには、内部的な変更(パフォーマンスやセキュリティ、その他の改善のために必要となる場合が多い)がアプリケーションに影響を与えてはならない。APIのアナロジに従うならば、互換性のない変更を最小限に留めると同時に、アプリケーションの適応に関する十分な情報を提供した上で、実際のデータ変更に先立って前方互換性のあるアップデートをデプロイする必要がある。このようなアプローチは、データベースにコンシューマ主導の契約(consumer-driven contracts)を適用することに他ならない。
Sabin氏によると、共有データベースを扱う上でこのようなアプローチが必要となるのは、アプリケーション開発者が共有データベースを“単なるストレージ”として見ているのに対して、データベース管理者(DBA)はそれを重要なビジネスデータのリポジトリと考えているという、異なった見解を仲介する必要があるからだ。理想とされるのは、各アプリケーションチームが自身のデータベースを所持した上でDBAの役割も兼ねることだが、実際には難しい場合が多い。
アプリケーション自体がスキーマなどの変更を必要とする場合、Sabin氏は、バッチサイズを小さくして(データベースの信頼性と一貫性の実現が難しくなるので)、対応するアプリケーションコードの変更と共に、一度に適用する変更を小規模にするようにアドバイスする。移行メカニズムの選択(ゴールドスキーマか移行スクリプトか)は、実施する変更の種類によって異なる。Sabin氏にとってこの２つのメカニズムは、相反するというよりも相互補完的なものだ。スキーマ変更の場合は、ターゲット(望ましい状態)のスキーマを記述した上で、SQLCompareなどのツールを現状とその状態との間に適用するという、ゴールドスキーマのアプローチが適切である。もっと複雑な変更であれば、DBDeployやFlyway、あるいはReadyRollといった移行スクリプトの方が適している可能性もある。
その他にSabin氏が推奨したのは、ツーリングに適合するようにデータベースを設計 - その逆ではない - して、データベース自体にデプロイ情報を追加することによって、問題のトレースや診断を容易にする方法だ。データベースの変更をデリバリパイプラインの一部として扱う方法も、監査性とコンプライアンス向上のために有意である。最後にSabin氏は、アプリケーション自体から直接アクセスできない、大規模でセキュアな(“プライベート”)データベースのビューのみをアクセス可能な小型(“パブリック”)データベースに保持するという、“プライベート”対“パブリック”のアプローチによって、(大規模なデータ侵害が続くような場合の)データセキュリティを大幅に向上させることが可能だ、と示唆している。
DevSecOpsというムーブメントの確立にある程度の時間を必要としたのと同じように、統合された継続的デプロイメントプロセスにデータベース変更を含めるというアイデアについても、さまざまな名称(Sabin氏は“DataDevOps”と呼んでいるが、一部では“DataOps”や“データベースライフサイクル管理(DLM)”とも呼ばれている)で呼ばれる状況がしばらく続いている。同じくWinOps 2017の講演者であるEduardo Piairo氏の場合は、
データベース変更を処理するプロセスを新たに定義するのではなく、それをアプリケーションやインフラストラクチャのコードと同じサービスライフサイクルに統合する、ということなのです。
この記事を評価
- 編集者評
- 編集長アクション