DDDとリソース割り当て

去年の夏前くらいにDDDまわりの勉強していた。でこのメモを書いていたので少し直して晒してみる。 前回の続編。

システムをコンテキストマップに対応するように実装することにする。

各サブコンテキストはモジュールやライブラリそしてサービスとして実装する。 システムのリリースにはコンポーネントの配置が欠かせない。 そして配置先のリソースの調達も必要となる。

ここでは、サブコンテキストをどの様にリソースに割り当てるかリソースはどのように調達されるか整理する。 具体的な話はあまりしない。

サブコンテキストの実装

サブコンテキストは実際にはコンポーネントとなる。 そしてその実装はサービス,コード,実行バイナリ,共有バイナリのどれかで提供する。

マイクロサービスアーキテクチャではサービスを重要視する。 ただし汎用サブコンテキストなどはそれ以外を選ぶことが多い。 またサイズが複数のコンテキストであっても小さなチームで維持できるならサービス化する根拠は弱い。

実行バイナリ,共有バイナリは利用者のリソースに配布したり配置したりする。 コードライブラリは他の提供形態から依存される。

振り返ってみる。

提供形態 稼動場所 配置方法
サービス インフラ 構成管理ツール
実行バイナリ ユーザー端末 マーケットプレイス,WEB経由での配布
実行バイナリ,共有バイナリ インフラ 構成管理ツール
コード 他の提供形態の中 ビルド

ここではインフラへの配置やクラウドからの調達について問題にする。

サブコンテキストの割り当てる先

サブコンテキストの実装には稼動場所が欠かせない。 しかし、そもそも外部サービスで済んでしまう場合はそれを利用できる。

ここでは前述のインフラやサービスの調達について整理する。

これを考えていた時に見つけた記事が参考になった。

  • インフラの調達
    • 物理機
    • IaaS
    • PaaS
    • CaaS
    • FaaS
  • サービスの調達
    • BaaS
    • SaaS

ここ数年はインフラ調達もInfrastructure as Code(IaC)は普通になりつつある。 そのためにはインフラの調達先はダイナミックインフラストラクチャが望ましい。

ダイナミックインフラストラクチャ

必要な条件は3つ。NISTのクラウドよりはゆるい。

  • プログラマブル
  • オンデマンド
  • セルフサービス

プログラマブルは調達がスクリプトから実行できることでRESTサービスやクライアントライブラリなどから利用できることを指す。 オンデマンドは必要に応じて即時調達ができるようになっていること。セルフサービスは調達時にリソースのキャパシティなど調整ができること。

物理機でもOpenStack Ironicとかつかってベアメタルクラウドにしたりすれば満たせる。

割り当て方法

FaaS,CaaS,PaaSへの実装配置についての定義づけは利用する基盤によって異なるのでそれを利用する。

ダイナミックインフラストラクチャでリソースを確保して実装を配置することを考える。 これには2つの段階がある。

1つは、SaaS,BaaS,CaaSを設定したりIaaSでリソースを調達する部分になる。 調達内容を宣言的にテキストで定義してプログラムのようにVCSを利用する。 このようなインフラ管理にプログラム的なアプローチを導入することをIaCと呼ぶ。

もう1つはIaaS,PaaS,CaaS,FaaSへ実装を配置する部分になる。 この設定も基本的にテキストで宣言的に記載してVCSで管理してCI/CDの対象にするのが望ましい。 このレイヤにプログラム的なアプローチを導入することをConfiguration as Code(CaC)と呼ぶ。

IaCではTerraformなどを利用する。

FaaS,CaaS,PaaSへ実装を配置する方法は提供サービスによって指定されるので従う。 IaaSなどダイナミックインフラストラクチャを利用するCaCではAnsibleなどが使われる。

IaCやCaCはプログラム的なアプローチを管理に適用する。 インフラコードなどはDDDでのサブコンテキストに対応するように抽象化するのが望ましい。

comments powered by Disqus