Webサービスにおけるインフラアーキテクチャの体系化とインフラアーキテクチャの選択自動化の研究課題についての整理と考察

第1回WSA研究会 開催概要 - Web System Architecture 研究会 (WSA研)で発表したときの予稿になります。
今回はWSA研の第一回ということもあり、自分自身で何をしたいのかという点を整理するための発表という形になりました。
まだ、整理や調査が不十分である状態ではありますが、WSA研のような場所で現状できているところまでを報告し、色々議論できたことでよりより調査を行えるかなと思っています。
このように、明確な成果でなくても発表し議論できるところがWSA研のいいところかなと思っている*1ので、興味ある人はぜひ参加を検討してみてください。

発表資料

speakerdeck.com

研究テーマ

Webサービスにおけるインフラアーキテクチャの体系化とインフラアーキテクチャの選択自動化の研究

研究背景

Webサービスに求められるユーザ要求は，高度かつ激しく変化する． それに伴い，webサービスのサーバサイドアプリケーションが動作するサーバやストレージ，ネットワーク(本稿ではWebサービスにおけるインフラと呼称する)は，ますます複雑化している． 一方で，仮想化技術，コンテナ技術，クラウドサービスの登場により，使用頻度の高いインフラストラクチャの構築はアーキテクチャのパターン化が進んでいる． これにより，サーバサイド技術者は要求を満たすために必要となる複雑なインフラストラクチャをアーキテクチャの組み合わせにより比較的容易に構築することができる． しかしながら，これらのアーキテクチャパターンには一長一短があり，効果的なインフラストラクチャを構築するためには対応するWebサービスに応じた適切なアーキテクチャを選択する必要がある． こうしたWebサービスの要求に対して適切なアーキテクチャを選択する作業はインフラアーキテクト設計者(以後，設計者とする)の経験や，ノウハウ，若しくは業界の”流行り”に頼っているのが実情である．

本研究はますます大規模かつ複雑化しているインフラストラクチャ構築を効率化し，設計者の暗黙知によらない，適切なアーキテクチャの自動選択を行う手法の確立を目指している． 本稿では，その初期段階として，アーキテクチャの体系化とインフラストラクチャ構築におけるアーキテクチャの自動選択を行うために必要となる課題を考察し，整理する． 加えて，課題の一部の考察も始めたので記載する．

研究課題の整理と方針

Webサービスの特性に応じて，適切なインフラアーキテクチャの選択自動化を実現するためには，以下の課題を解決する必要がある．

  1. 選択自動化のためのスコアリング手法の確立
  2. Webサービスの要素洗い出しとモデル化
  3. 既存のWebサービスの調査と分類
  4. インフラアーキテクチャの要素の洗い出しとモデル化
  5. 既存のインフラアーキテクチャの調査と分類

Webサービスの特性を入力値として，適切なインフラアーキテクチャが得られるようなスコアリング手法を確立する(1)．
そのためには，Webサービスとインフラアーキテクチャのモデル化が必要となる．
そこで，Webサービスとインフラアーキテクチャの要素を結びつけ，Webサービスのモデル化を行う必要がある(2)． Webサービスとインフラアーキテクチャでは，Webサービスのほうが抽象度が高くなるため，インフラアーキテクチャの要素に対し，Webサービスの要素を紐付けるほうがモデル化がしやすいと考えられる． Webサービスにはインフラに要求するサービスの特性を持つ． ただし，それはパラメータとしては一意に決定されず、サービスの分類として類型であってもサービスの特性として違う重みが付く可能性がある． よって，パターン化されたアーキテクチャそれぞれの持つ強み，弱みを評価要素とし，Webサービスの特性を評価要素に紐付けた解析をする必要がある． 例えば，ブログサービスAとBは同じブログサービスであるが，ネットワークトラフィック量というある要素について重み付けをした結果，違うサービス特性になる可能性がある．
したがって，簡単化のためにWebサービスを考慮する前に，インフラアーキテクチャのみでモデル化を行う(4)．
また，要素の洗い出しには既存のWebサービスとインフラアーキテクチャの調査と分類が必要となる(3,5)．

よって，本研究は大きく分けて下記のような段階を踏んで，研究を進めていく

  • インフラアーキテクチャのみのモデル化までを研究の第一段階とする(4,5)．
  • 第一段階の結果を踏まえて，Webサービスを考慮したモデル化までを研究の第二段階とする(2,3)．
  • 第二段階までのモデルを利用して，スコアリング手法を検討する(1)

既存のインフラアーキテクチャの調査と分類

一例として，高度化したインフラのアーキテクチャパターンとして注目されている，MicroServiceアーキテクチャ(以後，MSAとする)とServerlessアーキテクチャを例に取り上げ考察する． MSAでは，モノリシックなソフトウェアでWebサービスを構築するのではなく，ビジネス機能に沿った小さいMicroServiceが複数連携し，一つのWebサービスを構築するアーキテクチャである． 機能ごとにMicroService内で局所化出来るため，高度かつ激しくユーザ要求が変化するWebサービスに対応しやすいアーキテクチャであると考えられている． MSAはサービスの数が増えるため，モノリシックな一つの巨大なサービスのためのアーキテクチャとは異なった問題も出てくる． そのうちの一つとして，サービス数が増えることによるサーバの運用保守のコスト増加である． それらを解決する手段の一つとして注目されているのが，Serverlessアーキテクチャである． ServerlessアーキテクチャはAWS lambdaに代表されるFunction as a Service(FaaS)を利用し，運用するサーバの数を抑えつつ多くのサービスを構築することが可能となる． Serverlessアーキテクチャを採用するためには，基本的にFaaSを使うことになるため，AWSやGCPなどFaaSを提供しているクラウドを利用することになり，ある程度実装上の制限が発生すると考えられる． よって，Webサービスの要求に答えるため，MicroServiceアーキテクチャとServerlessアーキテクチャを採用するという場合もあれば，MicroServiceアーキテクチャを採用しつつも，Serverlessアーキテクチャではなく，また別の多数のMicroServiceを運用可能なアーキテクチャ(例えばFastContainerアーキテクチャ)と組み合わせて採用することも考えられる． このように，解決するためのアーキテクチャが複数提案はされているものの，アーキテクチャの問題点を解決するためのさらなるアーキテクチャが存在し，設計者は多くのアーキテクチャを組み合わせ，Webサービスの要求を満たすインフラ設計を行わなければならならず，インフラ設計のアーキテクチャ選択はより複雑になっている．

MSAとServerlessアーキテクチャの２つだけをとっても，要素の洗い出しには以下のような検討すべきことがある．

などがあり，MicroServiceアーキテクチャとServerlessアーキテクチャが，同じ分類として容易に比較できるものでは無いと考えられる． その他のアーキテクチャも含めたより詳細な調査を行ない，分類を検討していきたい．

また，分類と要素検討を行うための参考として，ソフトウェア工学などを参考にすることも考えている． 例えば，システム/ソフトウェアの品質モデルの国際規格であるISO/ICE 25010などの移植性，保守性などはインフラアーキテクチャの要素として利用できそうである． 一方で，ISO/ICE 25000シリーズはWSQB17による提言ではアジャイル開発や，クラウド環境下への対応は不十分であると提言されているので，アジャイル開発やクラウド環境化への課題に取り組んでいる研究，規格を調査する必要がある．

今後の課題

関連研究の調査が不足しているので引き続き調査を行う．加えて，最初の課題である既存のインフラアーキテクチャの調査と分類に取り掛かる．本稿ではMicroServiceアーキテクチャとServerlessアーキテクチャの簡易な考察を載せたが不十分であるので，その他のアーキテクチャとあわせてより深い考察を行う予定である．

参考文献

質疑応答とか

  • これができたとしてその先には何があるのか。我々が仕事をしなくても良くなるのか
  • これできるといいなと思ってました（e.g. 構築したはいいけどコストが非常に掛かるシステム見たことがあったり）口頭でも出た限り既存システムへの適用もしたくなるとか、あとビジネス的な要件にどのくらい追従できるかも気になりました。後者は例えばサービスがビジネスとして軌道に乗るか分からんので良いアーキテクチャで無くてもいいからスピード重視で作りたいとかあるかなーと
    • 実際には新規構築だけではなく、むしろそこから先のサービスの成長に合わせてインフラを成長させていくのが難しいと感じている。なので、現状のサービスと、新たに機能などが追加されたサービスの差分をサービス特性として入力とし、新たなインフラアーキテクチャを出力できたりする必要がある。最初は簡単化のために新規構築を対象とするが、最終的には差分なども考慮した特性で判別出来るようにしたい。例えば、最初はMonolithicだったが、規模が大きくなってきたのでMicroserviceにするときの適正なタイミングはどこかなど、考慮するべき項目はたくさんある。
  • アーキテクチャを体系化してインフラ構築などを加速していく、というのはある意味ソフトウェアのライブラリ化といっしょで再利用性を高めるのと似た利点を持つと感じがしました（そこを狙っているのかもしれません）

*1:成果があるならもっと影響力のある場所(論文やソフトウェアの公開、カンファレンスや大きな勉強会)での発表が良いでしょう。