SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2022 レポート(AD)

分散アプリケーションランタイム「Dapr」は現代のクラウドネイティブなアプリ開発に何をもたらすのか【デブサミ2022】

【17-A-7】CloudNativeな時代に求められるWebサービス基盤モデルの再考 - Daprについての考察と実装

  • X ポスト
  • このエントリーをはてなブックマークに追加

 スリーシェイクはSREの技術力に定評のある企業だ。今回はクラウドネイティブなサービス基盤モデルについての全体像、コンテナやKubernates、Daprのメリットなどについて、同社SREのnwiizo氏が解説する。

  • X ポスト
  • このエントリーをはてなブックマークに追加
株式会社スリーシェイク Sreake事業部・SRE nwiizo氏
株式会社スリーシェイク Sreake事業部 SRE nwiizo氏

インフラ自動化の歴史とDockerコンテナ

 まずはスリーシェイクについて簡単に紹介しよう。同社の強みはSRE技術で、顧客のシステム状況や段階に応じたSREの技術支援を行っている。さらに最近ではクラウドで脆弱性診断と改善方法を提供するサービス「Securify」を開発し、ベータ版を無償提供中だ。

 今回はクラウドネイティブの全体像とDaprを中心に解説する。nwiizo氏は「クラウドネイティブもソフトウェア開発も本質は徹底的な実践ですので、気軽に聞き流してもらえれば」と言う。コンテナについてはnwiizo氏おすすめの『コンテナ物語』(日経BP社)を読んでおくといいだろう。

 インフラ自動化の歴史を振り返ろう。かつて「Infrastructure as Document」時代は、システム運用担当者が秘伝のドキュメントにそって1台ずつ丁寧に設定しながら、アプリケーションを配置していた。秘伝なので出自不明で、更新されず、いつか腐る。分かる人が徐々に退職してなんとか動かすという綱渡りな状態だ。

 次に「Infrastructure as Code(IaC)」時代になると手順や前提をコードで表現できて、ドキュメントの更新が不要となり、コードを見れば全て分かるようになった。「約束された勝利の自動化」とも言われ、インフラが次々と生まれていった。nwiizo氏は「黎明期はシステム管理の自動化が、後にソフトウェア開発プラクティスの応用が焦点になりました」と指摘する。

 ところが、せっかくの自動化も腐る。最初はうまくいくが、OSやミドルウェアのバージョンアップ、属人化やシステムの複雑化などで徐々に腐っていく。「触るのが怖くなったら秘伝のタレが腐敗している合図」とnwiizo氏。

 そうしたなか「Immutable Infrastructure」と呼ばれるプラクティスが生まれてきた。一度構築した本番環境は更新やパッチを加えず稼働させるという考え方で、常にクリーンインストールから開始し、必要なものは全て固めてアプリを共存させない。

 つまり「アプリに必要なもの全てを特定のフォーマットで固めて展開するだけで起動する」。お気づきだろうか。これが(いま馴染みのある)コンテナとなった。2013年にDockerは「コンテナ」と呼ばれるソフトウェアパッケージを実行するものをリリースした。コンテナではベースイメージをダウンロードし、必要なソフトウェアはコンテナ内にインストールし、必要な設定はコンテナ作成時に仕込んでおく。これで運用が統一的になり、テスト環境・開発環境・本番環境も同じものとして扱えて、環境の違いによる影響を受けなくなった。

 なおコンテナはDocker以前にも存在しており、他のプロセスとのリソースを隔離するなど特別なプロセスを指す。いま私たちがコンテナと呼ぶものは2013年のDocker以降を指すことが一般的だ。

 クラウドで要求すれば下位のリソースが自動的に割り当てられるので、組み上げ方式から呼び出し方式への変化が起きた。コンテナで取り扱いが共通化され、アプリとインフラの依存関係を断ち切ることができるようになった。なおnwiizo氏は「アプリケーションファーストがクラウドネイティブではない」と念を押す。

クラウドによるアプリケーションファースト
クラウドによるアプリケーションファースト

クラウドネイティブ時代の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)、オーケストレーション層、ストラテジー層、サービス層で構成されている。

Webサービス基盤モデルについて
Webサービス基盤モデルについて

 発表された2017年から現在2022年までの間に「マイクロサービスを採用する企業や分散システムを適用する企業が増え、ストラテジー層の進化と解釈の拡大が起きた」とnwiizo氏は指摘する。例えばマイクロサービスアーキテクチャにおけるネットワークの課題解決のためのIstio、KubernatesベースのプラットフォームKnativeなどのアプリが誕生している。

 特に重要になるのがDapr(Distributed Application Runtime)。主にストラテジー層で動作し、効率的なクラウドネイティブアプリ開発を目指した分散アプリケーションランタイムだ。分散アプリケーションの実装上の課題を解決できるとされている。

Daprを理解するための2つのキーワード

 ここからはDaprを中心に見ていこう。Daprはサイドカーにより任意の開発言語やフレームワークで開発可能となる。またベストプラクティスをビルディングブロックとして提供する。重要なキーワードとなるのが「サイドカー」と「ビルディングブロック」だ。

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・ゲームといったさまざまな業界業種・領域での実績から、最適な課題設定と解決策を提示し、最新技術で、競争力のあるインフラ環境を構築、また維持できるチーム作りをご支援します。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/15631 2022/03/29 12:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング