Red Hatの須江です。
本記事は赤帽エンジニア Advent Calendar 2019の10日目です。 子供を皮膚科に連れて行ったりなんだりで、気づいたら12/11になってますが、細かいことは気にせず進めます。
セッション資料と動画
「データ指向アプリケーションデザイン」をメインテーマに選んだわけ
デジタルトランスフォーメーション(DX)がバズワード化して久しいですが、自分は常に「DXは目的ではなく手段なので、DXしたあとにどうありたいかのビジョンを持ち、そこから逆算していまやることを考える」ことが重要だと考えています。
ビジョンを持つためには、まずDX後の世界がどうなっているのかをイメージできるようになる必要があります。 そこで、2019/6/20に開催された「DX&Open Hybrid Cloud Day」では『DX後の世界はどうなるのか』というイメージを共有するために、書籍「アフターデジタル」で取り上げられている中国のデジタル化(デジタライゼーション)の実態を紹介しました。
要約すると、DX後の世界はだいたいこんな感じです。
- デジタルがリアルを飲み込む(OMO)ので、デジタルがビジネスの生命線になる
- あらゆる存在(人/モノ)から生成される大量のイベントデータをリアルタイム処理してアクションを起こすことが競合優位性構築に必須となる
- 様々なステークホルダーとダイナミックに連携して優れたユーザーエクスペリエンスを提供することが求められる
大雑把に言うと、現在GAFAクラスの企業がやっていることに近いことを、ふつーのエンタープライズ企業でもやるようになる、ということです。
DX後の世界では、現在とは桁違いの量のデータを扱いつつ、ビジネスの規模の変動(拡大/縮小)に柔軟に追随でき、システムアップデートやシステム障害によるサービス停止を極力回避するようなアーキテクチャが求められます。 それを経済的に合理的で、かつフレキシブルな形で実現するための戦略としては、いまのところCloud Nativeという考え方が妥当であると考えています。
Cloud Nativeを阻むものはなにか?
これまでOpenShift担当として、いろいろな方とコンテナ導入やCloud Nativeへの移行についてお話してましたが、モノリシックで巨大なRDBMSが主要な課題の一つといってよいかと思います。
アプリケーションをモダナイズしてマイクロサービスやサーバーレスに分解していくことは、簡単ではありませんが、そんなに難しいわけでもありません。 アプリケーションを分解するよりも、モノリシックで巨大なRDBMSを分解することの方がはるかに難易度が高いというのが、現時点での自分の見解です。
ありがちなRDBMS中心アーキテクチャ
エンタープライズシステムでよくありがちな、RDBMSを中心として複数のシステムが連携するアーキテクチャを誇張して表現したのがこちらです。(これは日本に限らずグローバルでもみられる傾向のようです。)
このアーキテクチャには以下のような課題があります:
- 巨大なRDBMSを「Data Hub」として利用
- RDBMSの能力増強は原則スケールアップ
- 能力増強に伴ってコストパフォーマンスが悪化
- スケールアップに実用上の上限がある
- RDBMSが苦手なワークロードの増加(特にSoE系)
- 追記(INSERT)をメインとするもの (例: IoT機器の計測データ)
- リレーショナルモデルでは非効率なもの (例: 時系列データ、グラフデータ)
- スキーマ(データ構造)を進化させることが難しい
- Schema on Write: 書き込み時にデータ構造を確定しなければならない
- 別のアプローチ) Schema on Read: スキーマの進化に適した方法、DataLakeでよく使われる
- RDBMSの能力増強は原則スケールアップ
- モノリシックなデータストアにすべてのデータを格納
- Write中心か、Read中心かによって、効率的な格納方式が異なる
- セカンダリインデックスを増やすと、Writeのパフォーマンスが落ちる
- トレードオフの調整が難しく、Try&Errorもやりにくい(DB全体に影響)
- Write中心か、Read中心かによって、効率的な格納方式が異なる
特にDXを進めるにあたって解決が必須となることが多く、近年になって本腰を入れて解決に取り組む動きが出てきたなという感触です。 去年くらいから折に触れてこういう話をしているのですが、最近になって「詳しく聞かせてください」と食いつかれることが明らかに増えてきました。(というか日本企業ほぼすべてこの問題で悩んでいるんじゃないかというくらいの食いつき。)
どうして巨大なRDBMSに依存するアーキテクチャになってしまったのか?
こうなった原因はいくつかあるとは思いますが、自分が考えるに「データの一貫性の担保が簡単かつ確実だから」、これに尽きるんじゃないかという結論に至りました。
で、セッションでは「データのTimeliness(即時性)」に関する制約を少し緩和してあげれば、RDBMSのトランザクション管理機構に頼らなくても「データのIntegrity(整合性)」を担保することは可能です、ということをお話しました。 実際、NoSQL系のDBなどではトランザクション管理機構を備えていないものもありますし、RDBMSであってもDBが分散しているとトランザクションは限定的にしか使えませんので、一般的に受け入れがたい条件ではないと思っています。
データ中心からイベント中心へ
Timelinessに関する制約を緩和できるならば、Integrityを担保しつつ、複数のシステムにデータを分散することが可能になります。 ということは、Cloud Nativeな分散システムにデータストアやデータパイプラインをのせることが可能になるわけです。
Integrityと分散合意
Cloud Nativeな分散システムにおいてデータのIntegrityを担保するという問題は、信頼性の低いインフラストラクチャの上でシステム全体として矛盾が発生しないようにするにはどうすればよいか?という問題に読み替えることができます。
この分野は既に研究が進んでおり、「分散合意」というアルゴリズムを利用することで解決できることがわかっています。 Kubernetesがリソースの管理に利用しているetcdも、内部ではRaftという分散合意アルゴリズムを利用してIntegrityを担保しています。
自分はコンピュータサイエンスの出身ではない(大学は物性理論物理学専攻です)ので、このへんはまだまだ勉強中というのが正直なところです。 詳しい解説はこちらの書籍をご参照くださいー。
分散処理の対象としてイベントを利用することの利点
分散システムにおいてデータを扱う場合、データをロストしないためにレプリケーション(複製)しておくのが一般的な対策です。 しかし、データが可変(mutable)だと、レプリケーションを含めた整合性の保証が非常に難しくなります。 そこで、分散システムにおいては不変(immutable)なデータを扱うようにすると、設計がシンプルになることが多いです。 具体的には、状態(=データベースのレコードに相当)をfactとして記録するのではなく、状態の変化を引き起こすイベントをfactとして記録するようにします。
このあたりは、以下のブログエントリに詳しく解説されています。ぜひご一読を。
ログベースメッセージブローカー(LBMB)を中心としたアーキテクチャ
イベント中心なアーキテクチャを採用する場合、重要なのは
- (a) イベントが確実に伝達できること
- (b) イベントの伝達経路がボトルネックにならないこと
です。
エンタープライズシステムでよく使われているメッセージブローカー(例えばIBM MQなど)は、(a)は満たしていますが、(b)が課題になることが多いです。
そこで、(a)(b)両方を満たすものとして登場したのがApache Kafkaに代表される「ログベースメッセージブローカー(LBMB)」です。 従来型メッセージブローカーとLBMBは、メッセージ(イベント)の取り扱いのセマンティクスが異なります。
これらは排他的なものではなく、ケースバイケースで使い分けるべきものです。(機能や適用シーンが異なるので、KafkaがあるからMQいらないよねとはならないです。)
LBMBを中心に据えたアーキテクチャは次のようになります。
さらにこれを推し進めて、必要がなければRDBMSを使わずに直接LBMBにイベントを入れてもいいわけです。
こうすることで、Cloud Nativeスタイルに移行しつつ、全体を最適化することがやりやすくなると考えています。
「ゼロトラストネットワーク」について
セッションでは時間がなく、あまり触れることができませんでしたが、Cloud Native時代のセキュリティは根本的に考え直す必要があると思ってます。
具体的には、伝統的なネットワークのゾーニングによるアクセス制御から、次の世代のアーキテクチャにステップアップしていくべきではないでしょうか? マイクロサービスやサーバーレスを駆使して、データも分散処理できるような仕組みを作って、Cloud Nativeなアーキテクチャに移行した場合、「ネットワークのセグメント」という粗い粒度でのアクセスコントロールではもはや不十分です。
ではどうするのかというと、「ゼロトラストネットワーク」という考え方がヒントになると思います。
具体的な事例としては、書籍中でも紹介されているGoogleのBeyondCorpが参考になるでしょう。
ゼロトラストネットワークは現在発展中の分野で、具体的な製品とかソリューションが揃っているわけではありません。 いろいろと試行錯誤してソリューションを作っていくフェーズです。
しかしながら、この考え方を取り入れたプロダクトは今後増えていくでしょう。 例えばIstionの内部コンポーネントであるCitadelが参考になると思います。
https://istio.io/docs/ops/deployment/architecture/#citadel
OpenShift4の話が少なかった・・・
取り上げるべきトピックの優先度を勘案した結果、今回はOpenShift自体の話はあまり入れられませんでした。ゴメンナサイ。 他のセッションではOpenShiftの話とかOperatorの話とかたくさんありますので、補完いただければと。。
真面目な話ですが、今後はシステムのモダナイゼーションやCloud Native化は「アプリケーション」と「データ」の2軸で考えていくべき、と考えておりまして、今回は「分散システムにおけるデータの扱い」が目下最重要でお伝えすべきことを判断しました。 そこで、OpenShift自体の話や、Service Mesh/Serverlessの話は必要最小限にさせていただきました。
アプリケーションアーキテクチャの話は、DBの解体と、データパイプラインのCloud Native化が進展すれば、自然とCloud Nativeに向かっていくものと考えています。 逆説的ですが、そうすればマイクロサービスやサーバーレス(Function)を使うことが当たり前になっていくと思います。
まとめ
マイクロサービスとかサーバーレスを活用したモダンでCloud Nativeなアーキテクチャにステップアップするには、データをどうするかも含めて考えなきゃね、という至極当然の話でした。
Kubernetes Operatorが登場したことで、データベースやメッセージブローカーなどのステートフルワークロードをk8sに乗せる流れができつつあります。 そのへんの話を詳しく聞きたい方は、ぜひOpenShiftコミュニティの大忘年会にお越しください!!!
