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