クラウドネイティブ時代のWebサービス基盤モデルとDapr
いよいよ本論。クラウドネイティブとWebサービス基盤に移ろう。クラウドネイティブやKubernatesを使えば可用性が高まるように期待されがちだが、シングルノード100台でアプリを動かしたらどうだろうか。あくまでもクラウドネイティブやKubernatesはリスク回避の方法の1つ。
そもそもクラウドネイティブ技術とは、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらすもの。コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型APIを用いることで、回復性、管理力、可観測性のある、疎結合なシステムを実現する。
疎結合なシステムとは、1つのサービスが停止しても全体が停止することなく一部のサービスは継続できる、サービスごとに独立してスケールリソースを最適化できる、小さな単位で開発することで新機能の追加が容易になることだ。
なおKubernatesはGoogleが開発し、今ではCloud Native Computing Foundationが管理しているGolang製のオーケストレーションツールだ。特徴は先述したようにイミュータブルなインフラストラクチャ、宣言的な設定、自己修復機能がある。開発者から見ると、リソースをあらかじめ用意することなく、コードで呼び出して、一部壊れても自動で修復できるようになっているのがメリットだ。
そうしたなかnwiizo氏は2017年に松本亮介（まつもとりー）氏がWebサービス基盤モデルに関して発表した論文[※1]を引用した。サービスレイヤーごとに整理して解説されている。
[※1]『FastContainer: Webアプリケーションコンテナの状態をリアクティブに決定するコンテナ管理アーキテクチャ』
Webサービス基盤モデルは下から、インフラストラクチャ層、コンテナランタイム層、CRI（Container Runtime Interface）、オーケストレーション層、ストラテジー層、サービス層で構成されている。
発表された2017年から現在2022年までの間に「マイクロサービスを採用する企業や分散システムを適用する企業が増え、ストラテジー層の進化と解釈の拡大が起きた」とnwiizo氏は指摘する。例えばマイクロサービスアーキテクチャにおけるネットワークの課題解決のためのIstio、KubernatesベースのプラットフォームKnativeなどのアプリが誕生している。
特に重要になるのがDapr（Distributed Application Runtime）。主にストラテジー層で動作し、効率的なクラウドネイティブアプリ開発を目指した分散アプリケーションランタイムだ。分散アプリケーションの実装上の課題を解決できるとされている。
Daprを理解するための2つのキーワード
ここからはDaprを中心に見ていこう。Daprはサイドカーにより任意の開発言語やフレームワークで開発可能となる。またベストプラクティスをビルディングブロックとして提供する。重要なキーワードとなるのが「サイドカー」と「ビルディングブロック」だ。
サイドカーとは、バイクのサイドカーのようにサービスに横付けされているもの。サービスの一部ではなく、サービスに接続されているのがポイントだ。サイドカーはアプリケーションコンテナを拡張して機能を追加する。分散システムにおけるデザインパターンの1つとなる。
DaprにおけるサイドカーはHTTP/gRPCの通信が可能であれば開発ができて、公式SDKも各種提供されている。例えばCOBOLのような古いアプリがあり、S3に対応していないとする。そういう面倒な時に、サイドカーパターンを利用することで別のアプリでファイルの共有ができるなど、解決の糸口になる。
もう1つ、ビルディングブロックとは、一般的にはシステムアーキテクチャを構成する要素だが、Daprでは利用可能な機能（コンポーネント）群を指すことが多い。マイクロサービスのベストプラクティスを体系化して機能として実装するものとなる。2022年2月時点でDaprのバージョンは1.6で、ビルディングブロックは「サービス間呼び出し」「状態管理」「パブリッシュとサブスクライブ」「バインダー」「アクター」「可観測性」「シークレットの管理」「構成設定」の8つが用意されている。詳細は公式ドキュメントを参照しよう。
最後にリポジトリにおけるDaprによる抽象化について。リポジトリとはDDDのレイヤードアーキテクチャで提唱されているもので、インターフェースを定義することでインフラ層を抽象化し、依存性が逆転する。これでモックの差し替えができて、アプリケーション層のユニットテストが可能になる。
基本的にリポジトリは抽象化とレイヤー化を同時に行う。Daprは先述したように、ビルディングブロックと公式SDKでプロトコルの抽象化が可能だ。抽象化に合わせた実装をしなくてもいいので、全体の実装量が減るので多少楽になるだろう。
ではDaprによってComplexity（認識や変更を困難にするソフトウェア構造に関する全てのもの）は解消されるのか。nwiizo氏は「Daprにより、抽象化に関する一部のメリットは必ず得られると思います。Daprの抽象化はDaprがやりますが、レイヤー化は自分たちがやることを忘れないでください。MockClientのような話がgo-sdkでも出てくればいいですが、現時点ではないので自分たちで用意して実装する必要があります。今後に期待しています」と話す。
最後にnwiizo氏は「どれだけいいプラグインやプラットフォームがあっても、共通で考えられるものはある程度決まっていますので、塩梅を見ながらいいソフトウェアを選びましょう。参考資料を記しておきますので、参考になさってください」と述べてセッションを締めくくった。
SRE総合支援サービス「Sreake（スリーク）」
「Sreake」は、SRE（Site Reliability Engineering）による設計及び構築支援から人材育成まで、クライアント組織に深く入り込んだコンサルテーションを提供しています。AWS/GCPなどのマルチクラウドの導入や、KubernetesやIstioを始めとしたクラウドネイティブに特化した技術に強みを持っております。金融・医療・動画配信・AI・ゲームといったさまざまな業界業種・領域での実績から、最適な課題設定と解決策を提示し、最新技術で、競争力のあるインフラ環境を構築、また維持できるチーム作りをご支援します。
