CACのAWS導入支援サービス「enterpriseCloud+」

開発・リリースフローの変化 前編

1. ロボット管理プラットフォーム連携基盤の構築

サーバーレスアーキテクチャ、特に昨今の技術ではリリースフローやその仕組みツールもすでに変化している。以下に例をあげる。

1. クラウドリソースはCloudFormation、Terraformなどのコードで定義する
2. クラウドリソースもアプリケーションのビルド・デプロイと類似したフローで作成される
3. その中に内包されるアプリケーションはクラウドリソース側の仕様次第で同時にリリースすることしか出来ないものもあるし、別々に管理することが出来るもの、任意に選べるものもある
4. 別々に管理することが出来るものは(AWSにおける例としてはECSのタスク定義がそれに該当するが)バージョンは前に進むことしか出来ない仕様になっている
5. ECSもKubernetes(EKS)は任意に選ぶことが出来る機能を内包しているが、その仕組みをどう活用するかは使う側に委ねられている
6. AWS Lambdaも同等の機能を持っているが、この仕組みはECSとKubernetesとは異なる
7. API Gatewayも似た機能も持っているが、アプローチが異なる

変化点はこれだけではなく、それぞれのリリース時に周辺の依存リソースへの影響を考慮してルーティングする技術(CloudFront、Appmesh、CloudMap、Route53)と、その他リソースをバッキングサービスとして付け替えする機能、権限をロールベース・アクセス・コントロール（RBAC）とそのポリシーで制御する機能(IAM、Kubernetesのサービスアカウント)を組み合わせて全体を統制する必要がある。
そして、AWSはあくまでこれらの技術を簡単に使用できるフレームワークを提供しているだけなので、実際は利用する側の解釈と設計に委ねられる。AWSはこの問題に対するサンプル案やベストプラクティス（参考ページ：https://aws.amazon.com/jp/architecture/well-architected/?wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc）を提供しているが、AWSがカバーする範囲は開発フローや運用の全体像を俯瞰したものではなくAWS内部の話に限定していることに留意する必要がある。これは、AWSが情報提供している範囲外の要素も含めて全体像をイメージする必要があるということだ。

また、リリースの観点では環境変数、パラメータなどこれまで存在しない、もしくは使ってこなかった概念が出てくることに注意が必要だ。この概念の呼び方はツールや言語、環境によって異なる上に用途が複数あるのが理解を進める上で混乱を招く原因になっている。
以下に用途の例をあげる。

1. 環境差分を吸収するための変数
2. 任意のサービスをバッキングサービスとしてアタッチするためのパラメータ
3. その両方の目的のための変数
4. 環境には依存しないが汎用性をあげるためにコンフィグとして外出しされているパラメータ
5. センシティブ情報(パスワードなど)

更にこれらの要素は、その扱いによって格納場所が異なる上に動的に生成される(もしくは動的に生成した方が、管理が容易になる)ものもあり、リリース時に結合されて実際の環境へ反映される。そして、上記のうち明確にコード内で定義せず、定義する場所を例示できるのはセンシティブ情報だけだが、これもまた用途・目的によって定義場所が変わる。以下に例をあげる。

図1 サポートされるセンシティブデータの格納場所の例。提供される機能はあくまで例であり、本記事公開時点での情報である。

これは一例だが、これらの機能を目的別に使い分けて推奨される環境にガイドラインやベストプラクティスに従いつつ格納すべきというのが多くのドキュメントに記述されている。
それだけでなく、提供される機能は日々増えていくのも課題であり、一概にこうするのがベストであるという回答は無いかもしれない。

しかしながら、要件に応じて使用する要素についてはまとめることが可能である。サーバーレスアーキテクチャのリリース時に使われる技術の概念的ポイントだけを抜き出して以下の図にまとめてみた。

図2 
図の中で示している通り、コードは大きく以下の3種類に分かれる。

1. パラメータを定義もしくは生成するためのもの、及びテンプレート
2. アプリケーションまたは関数、静的コンテンツのためのソースコード
3. クラウドリソースを定義するためのコード

本題とは外れるが、これらを同時に管理することも使用するツール次第では出来るし、出来ない場合もある。前者はAWS CDKやPlumiがその例だ。CloudFormationは後者に該当し、Hashicorp Terraformはどちらも出来る。

CI/CDを実現した場合は、ビルドされたアプリケーションはアーティファクトと呼ばれる概念でパッケージングされ、デプロイ時にそれを利用するが、パラメータの埋め込みはビルド時・デプロイ時にそれぞれ別に定義できる。環境差分に近いものはデプロイ時に合成し、使用するリソースをバッキングサービスとして利用する。環境に依存しないものはビルド時に埋め込む。この時、同時にクラウドリソースをデプロイ時に作成もしくは更新する場合もあるし、しない場合もある。この選択はアプリケーションをリリースする対象のクラウドサービスの仕様次第である。コンテナを利用する場合は明確に分離され、ビルドする際はアプリケーション中心の視点で、デプロイする際は対象の環境を中心とした視点で分類する。Lambdaはコンテナもサポートされたため、どちらも選ぶことが出来る。また、図で示した通り実現する内容次第ではビルド時に参照する場合もあるし、デプロイ時に参照する場合もある。前者の場合は既存の環境の情報を元にパッケージングそのものを動的に定義する場合(リージョン単位でロードする機能を変えてパッケージを出力するなど)、後者はすでに解説した通り環境に合わせてパッケージの振る舞いを定義する。

最終的にリリースされるクラウドリソース(図の青地の部分)はパラメータや既存のクラウドリソースから取得した情報などを元に動的に定義されるようにするのがサーバーレスアーキテクチャではポイントとなるが、これを実現するためには「The Twelve-Factor Apps」の要件を満たさなければならないし、逆に管理上の都合から考えれば自ずと定義された形になる。

これは「鶏が先か、卵が先か」のパラドックスであり、答えはどちらでもない。あくまで「The Twelve-Factor Apps」は実現した後の結果や条件、判断基準を示しているだけであり、管理上の都合もマネージドサービスがそれに合わせた機能を持っているからそのように見えるだけでありどちらも因果関係は薄い。どちらかというと迅速なアプリケーション開発、システム開発をしようという目標とクラウドや開発技術とツールやサービスを組み合わせた結果生まれたものであり、マネージドサービスはそれに合わせて機能を追加されたと解釈したほうが無難だ。この問いは誰が何をやろうとして、その過程で副産物が生まれたかであり、副産物の方をいくら見ても解はない。「The Twelve-Factor Apps」はその目標やアプローチを理解する方が重要であり、具体的にどうやって考えるかについては「Beyond the twelve factor app」の中で解説されている。

EKS(Kubernetes)の場合は図のアプリケーションがDockerImageに相当し、クラウドリソースはKubernetesのリソースに相当する。クラウド環境においても上限は存在するが、Kubernetesの場合はそのクラスターに割り当てられたリソースによって明示的に定められているのが大きな違いだ。そして、コンテナを扱う場合はDockerImageの格納先はDockerHubやECRであり、それぞれのImageに対してタグを紐づけて管理することになるので、上図よりも視点によっては複雑になる。

2. グリーンフィールドとブラウンフィールドとサーバーレスアーキテクチャ

サーバーレスアーキテクチャの議論はクラウド導入時に言われたグリーンフィールドとブラウンフィールドの問題に近い。グリーンフィールドはソフトウェア開発の定義だが、全く新しい環境で白紙の状態から開発を行い、大きな制約や依存関係がない状態を指す。ブラウンフィールドソフトウェア開発は既存のシステムもしくはアプリケーションと共存する形で新規に開発もしくは改修を行うことを指す。グリーンフィールド・ブラウンフィールドの用語はIT業界だけの用語ではなく、様々な業界で使われている。

サーバーレスアーキテクチャ導入時においてはグリーンフィールドが強制されるのが問題である。クラウド移行時の初期は物理的な環境から、VMへの移行、クラウドのIaaS環境への切り替えはグリーンフィールド・ブラウンフィールドの選択肢があり共存も可能であった。しかしサーバーレスアーキテクチャは物理サーバーとは縁が薄く、どちらかと言うとグリーンフィールドな世界に分類される。よって、その技術を最大限に活かして導入した場合は、この概念で指摘されているデメリットがそのまま業務全体に影響してくる。

1. 学習曲線が急激で、学習コストが高い
2. 変化が組織に影響する
3. 移行時のコストがかかる

けれども、これもまた「鶏と卵」のパラドックスであり、学習が先か後かであれば同時に、つまりやりながら覚えるものであり、変化が組織に影響するというのも組織を変化させながらやらなければ実現できない。移行時のコストはそれをどれだけ効率よくやるかという一時的な課題なので答えはブラウンフィールド開発に比べた場合、規模次第では安くなるはずだ。

つまり制約上の問題でグリーンフィールドソフトウェア開発にならざるを得ないが、スタート地点は様々でありどちらかと言うと以下の点の方が考慮すべき点である。

1. どうやって学習していくか
2. どこまで出来たら学習できたと判断するのか
3. どうやって組織を変えていくのか
4. 上記の結果から生まれたシステムへ既存のワークフローをどうやって移植するのか

どこまで出来たら学習できたと判断するのかは、決めの問題でありそこを議論しても意味はなく、また学習の材料となるものはサーバーレスアーキテクチャではないものから生まれたわけで、結果を元にいくら考察を重ねても結果には至らない。また、このパラドックスから外れるが、今のグリーンフィールドは未来のブラウンフィールドであると言う避けては通れない問題がある。

サーバーからVMへ、データセンターからクラウドへなどの流れが過去にあったが、モノシリックアプリケーションからサーバーレスアーキテクチャ・マイクロサービスの流れも同様であり、過去のグリーンフィールドが今のブラウンフィールドになっている。イメージの描き方・解釈の仕方の話になるが、実際に構築している側の目線では基盤技術に見えるものも、全体を俯瞰して見た場合はそうでは無い可能性が存在しており、事実その移り変わりが激しい。視点と主語次第で定義は変わるが、ブラウンフィールド・グリーンフィールドそれぞれに存在する課題を組織的に解決するためには、客観的な視点を培う必要があるのではないだろうか？