Red Hatの須江です。
本記事は赤帽エンジニア Advent Calendar 2019の10日目です。 子供を皮膚科に連れて行ったりなんだりで、気づいたら12/11になってますが、細かいことは気にせず進めます。
デジタルトランスフォーメーション(DX)がバズワード化して久しいですが、自分は常に「DXは目的ではなく手段なので、DXしたあとにどうありたいかのビジョンを持ち、そこから逆算していまやることを考える」ことが重要だと考えています。
ビジョンを持つためには、まずDX後の世界がどうなっているのかをイメージできるようになる必要があります。 そこで、2019/6/20に開催された「DX&Open Hybrid Cloud Day」では『DX後の世界はどうなるのか』というイメージを共有するために、書籍「アフターデジタル」で取り上げられている中国のデジタル化(デジタライゼーション)の実態を紹介しました。
要約すると、DX後の世界はだいたいこんな感じです。
大雑把に言うと、現在GAFAクラスの企業がやっていることに近いことを、ふつーのエンタープライズ企業でもやるようになる、ということです。
DX後の世界では、現在とは桁違いの量のデータを扱いつつ、ビジネスの規模の変動(拡大/縮小)に柔軟に追随でき、システムアップデートやシステム障害によるサービス停止を極力回避するようなアーキテクチャが求められます。 それを経済的に合理的で、かつフレキシブルな形で実現するための戦略としては、いまのところCloud Nativeという考え方が妥当であると考えています。
これまでOpenShift担当として、いろいろな方とコンテナ導入やCloud Nativeへの移行についてお話してましたが、モノリシックで巨大なRDBMSが主要な課題の一つといってよいかと思います。
アプリケーションをモダナイズしてマイクロサービスやサーバーレスに分解していくことは、簡単ではありませんが、そんなに難しいわけでもありません。 アプリケーションを分解するよりも、モノリシックで巨大なRDBMSを分解することの方がはるかに難易度が高いというのが、現時点での自分の見解です。
エンタープライズシステムでよくありがちな、RDBMSを中心として複数のシステムが連携するアーキテクチャを誇張して表現したのがこちらです。(これは日本に限らずグローバルでもみられる傾向のようです。)
このアーキテクチャには以下のような課題があります:
特にDXを進めるにあたって解決が必須となることが多く、近年になって本腰を入れて解決に取り組む動きが出てきたなという感触です。 去年くらいから折に触れてこういう話をしているのですが、最近になって「詳しく聞かせてください」と食いつかれることが明らかに増えてきました。(というか日本企業ほぼすべてこの問題で悩んでいるんじゃないかというくらいの食いつき。)
こうなった原因はいくつかあるとは思いますが、自分が考えるに「データの一貫性の担保が簡単かつ確実だから」、これに尽きるんじゃないかという結論に至りました。
で、セッションでは「データのTimeliness(即時性)」に関する制約を少し緩和してあげれば、RDBMSのトランザクション管理機構に頼らなくても「データのIntegrity(整合性)」を担保することは可能です、ということをお話しました。 実際、NoSQL系のDBなどではトランザクション管理機構を備えていないものもありますし、RDBMSであってもDBが分散しているとトランザクションは限定的にしか使えませんので、一般的に受け入れがたい条件ではないと思っています。
Timelinessに関する制約を緩和できるならば、Integrityを担保しつつ、複数のシステムにデータを分散することが可能になります。 ということは、Cloud Nativeな分散システムにデータストアやデータパイプラインをのせることが可能になるわけです。
Cloud Nativeな分散システムにおいてデータのIntegrityを担保するという問題は、信頼性の低いインフラストラクチャの上でシステム全体として矛盾が発生しないようにするにはどうすればよいか?という問題に読み替えることができます。
この分野は既に研究が進んでおり、「分散合意」というアルゴリズムを利用することで解決できることがわかっています。 Kubernetesがリソースの管理に利用しているetcdも、内部ではRaftという分散合意アルゴリズムを利用してIntegrityを担保しています。
自分はコンピュータサイエンスの出身ではない(大学は物性理論物理学専攻です)ので、このへんはまだまだ勉強中というのが正直なところです。 詳しい解説はこちらの書籍をご参照くださいー。
分散システムにおいてデータを扱う場合、データをロストしないためにレプリケーション(複製)しておくのが一般的な対策です。 しかし、データが可変(mutable)だと、レプリケーションを含めた整合性の保証が非常に難しくなります。 そこで、分散システムにおいては不変(immutable)なデータを扱うようにすると、設計がシンプルになることが多いです。 具体的には、状態(=データベースのレコードに相当)をfactとして記録するのではなく、状態の変化を引き起こすイベントをfactとして記録するようにします。
このあたりは、以下のブログエントリに詳しく解説されています。ぜひご一読を。
イベント中心なアーキテクチャを採用する場合、重要なのは
です。
エンタープライズシステムでよく使われているメッセージブローカー(例えば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
取り上げるべきトピックの優先度を勘案した結果、今回はOpenShift自体の話はあまり入れられませんでした。ゴメンナサイ。 他のセッションではOpenShiftの話とかOperatorの話とかたくさんありますので、補完いただければと。。
真面目な話ですが、今後はシステムのモダナイゼーションやCloud Native化は「アプリケーション」と「データ」の2軸で考えていくべき、と考えておりまして、今回は「分散システムにおけるデータの扱い」が目下最重要でお伝えすべきことを判断しました。 そこで、OpenShift自体の話や、Service Mesh/Serverlessの話は必要最小限にさせていただきました。
アプリケーションアーキテクチャの話は、DBの解体と、データパイプラインのCloud Native化が進展すれば、自然とCloud Nativeに向かっていくものと考えています。 逆説的ですが、そうすればマイクロサービスやサーバーレス(Function)を使うことが当たり前になっていくと思います。
マイクロサービスとかサーバーレスを活用したモダンでCloud Nativeなアーキテクチャにステップアップするには、データをどうするかも含めて考えなきゃね、という至極当然の話でした。
Kubernetes Operatorが登場したことで、データベースやメッセージブローカーなどのステートフルワークロードをk8sに乗せる流れができつつあります。 そのへんの話を詳しく聞きたい方は、ぜひOpenShiftコミュニティの大忘年会にお越しください!!!
Red Hat forum Tokyo 2019で講演した内容のフォローアップ記事を紹介しています。
記事のリンク