ギーク感あふれるデジタル庁クラウドチームのデータベースへの理解

筆が滑っただけだと思うが、デジタル庁クラウドチームのデータベースへの理解が不十分な気がしてきたので指摘したい。データ中心主義（DOA）からプロセス中心主義（POA）に逆戻りしている。また、業務要件からデータベースのトランザクションが満たすべき性質を考えていない。

古臭い話で、クラウド大好きギークの皆さんは好きではない概念だと思うが、忘却すると地獄の業火に焼かれることになる。

1. DOAへの無理解

DOAは、アプリケーションの刷新されても処理する業務データは変わらないことから、データベースはアプリケーションと独立して設計する方法だ。

アプリケーションにあわせてデータを構築するPOAだと、アプリケーションの刷新や増強ごとにデータベースの作り直しがいるし、同じデータが複数の場所に異なる形式で存在して、しかも一致しないようなことが起きがちだ。原本と写本と言う概念がないので、勝手にあちこちで更新しているぞ問題。

さて、山本教仁CCOの「ガバメントクラウドでのクラウド最適なアーキテクチャのサンプル」に、

データベースは業務ごとに分離
RDBは1つに統合するのではなく、業務ごと（今回の例であれば、届出・申請、審査・承認、レポート）で分離します。

と記述がある。サンプルではなくてベストプラクティスと言いたいのではないかというのはさておき、アプリケーションどころか業務タスクごとにリレーショナルデータベース（RDB）をつくれと書いてある。DOAの観点から言うと、避けるべき行為だ^*1。例で言うと、届出と承認の関係を見たくなったときに、届出と承認のデータベースが分かれていたら、リレーションをとって調べるのが困難になる。

さらに、

ハードウェアが高価だった時代はDBの統合に大きな意味がありましたが、クラウドになりインスタンスを分けることがコストにそこまで影響しなくなったため、人件費に直結するメンテナンスや運用の容易性の方をより重視してサービスレベルや運用パターンで最適なデータベースを使用し、分離して管理します。

とあり、データベースを統合する理由について理解できていないのが分かる。

2. 業務要件への乏しい意識

現在のデータベースのトランザクション処理には、RDB向きの常に厳密に数字をあわせていくACID^*2と、NoSQL向きの最後だけ辻褄をあわせるBASE^*3と言う2つの方針がある。パフォーマンスはBASEになるが、ショッピングサイトでした注文が、店に在庫切れでキャンセルとなりましたと一方的に宣告されるようなことが起きうる。

上述のデータベースの分離の話の続きを見てみよう。

分離する基準としては、その業務アプリケーションに要求されるサービスレベルや運用パターンで分離します…広いユーザ層から24時間365日受け付ける届出・申請はスケーラビリティを重視し、RDBでInsertとSelectのみにしてUpdateを無くしDBMSのロックをシンプルにして大量リクエストをさばけるようにするか、スケーラビリティに強いNoSQLも検討します。

サービスレベルは可用時間や応答速度などを指す。RDBのこの使い方はBASE利用になると思われ^*4、NoSQLもスケールさせるにはBASE以外の選択肢はない^*5。業務要件からトランザクション処理が定まる可能性を考慮していない。業務要件の方を変えると言う選択肢もあるのだが、常にできるわけではない。

3. まとめ

インフラ周りのパフォーマンスやメンテナンスなどの運用の容易さを重視し、業務要件周りの概念が軽視されている。山本教仁CCOが、DOAとPOA、ACIDとBASEについて知らないはずがない。どれも教科書的な話である。しかし、立場や文脈の都合なのだとは思うが、モダンなクラウドを推奨しているうちに、システム構築の全体像を見失っていたりしないであろうか心配になる。

*1パフォーマンスの都合で、複数のテーブルに同じデータを持たせたり、複数のハードウェアにデータベースを分散する場合もあるのだが、妥協として行うものだ。なお、マテリアライズドビューやレプリケーション機能によって、設計に無理なく同様の行為ができる時代になっている。なお、山本教仁COOが言及しているAWSのRead Replicaもレプリケーション機能でパフォーマンスを出す技術。

*2ACIDは、不可分性・一貫性・隔離性・永続性が満たされた処理のことを言う。振込みを考えよう。ある口座の残高が減り、別の口座の残高が増える。二つの処理で一つの取引になり、これは分割不可能であり、誤ると一貫性がなくなる。また、残金を確認した後に、振込みをすることを考えよう。この二つの処理の間に、別の振込みが行われると、残金を確認が無駄になるので、他の処理の割り込みは禁止する必要がある（隔離性）。そして、一度実行した割り込みは、何かの拍子でなかったことにはできない（永続性）。

*3BASEは、ひとつひとつの処理において一貫性を持たせるのではなく、最後に辻褄をあわせようと言うアプローチ。一つの文章を複数の人間で編集する場合、ACIDだと交換日記のように順番に作業することになるので非効率が、BASEだとそれぞれ勝手に編集して最後に統合して辻褄をあわせるので効率がよい。

*4updateをしないでselectとinsertでASIDを実現しようとすると、表ロックが必要になり遅くなる。update（とselect for update）であれば行ロックで済む。

*5具体的な製品名と方法を確認していないので誤解かも知れないが、製品によってはNoSQLでASIDになる運用も可能と言う記述を見かける。