トップ > Architecture > Webシステムアーキテクチャの地図を描く構想

Webシステムアーキテクチャの地図を描く構想

Architecture

この記事は第5回Webシステムアーキテクチャ研究会の予稿です。

はじめに

Webサービスにおいては、スマートフォンの普及によるアクセス増加に対してスケーラビリティを持ち、個人向けだけでなく企業向けサービスの可用性の要求に耐えられるようなシステム設計が必要とされている。 さらに、Webサービスが人々の生活に浸透したために、Webサービス事業者はサービスを長期間運用することが当たり前となっている。 その間、新機能開発、ソフトウェアの実行効率化、セキュリティ向上などを目的に、システム管理者は自身が管理するソフトウェア群を更新しつづける必要がある。

このような多様な要求を満たすために、Webサービスを開発・運用するエンジニアには、OSやデータベース、ネットワーク、分散システム、プログラミング言語処理系などのコンピュータ工学における広範囲の基礎知識と、ミドルウェア、オペレーション自動化のためのソフトウェア、クラウドサービスなどを駆使するための知識が必要となる。 さらに、これらの知識を組み合わせ1つのシステムを構築し、運用していくための技術が必要となる。 以上のように、大学の教科書にあるような古典的な情報工学の基礎知識と現場でのボトムアップな応用知識の両方とその組み合わせが必要となり、既存の教科書だけでは学べないため、体系立てて学ぶことが難しくなっている。 そこで、Webシステム開発・運用の現場の経験を踏まえつつ、生きた知識の地図をつくることが重要となる。

しかし、従来の情報工学の教科書では、情報工学における複数の分野の知識を組み合わせてシステムを構成する手法そのものは記述されていない。 また、Webサービス開発と運用の現場では、情報工学の知識があっても、未経験でも理解できるような形で現場の経験が言語化されていない。 言語化されていたとしても、Web上のブログ記事やスライド資料などでは、断片的であったり、特定の実装や個別の経験に依存した情報となっていることも多い。 類似の問題意識を書籍『Infrastructure As Code』1の冒頭で著者は次のように述べている。

コードとしてインフラストラクチャを管理するという考え方は、従来のインフラストラクチャ管理とは大きく異なる。 私は、この転換をどのように進めたらよいかがわからず苦労しているチームをたくさん見てきた。 しかし、これらのツールを効果的に使うためのアイデア、パターン、プラクティスは、カンファレンスの講演、ブログポスト、個別の論文に散らばっている。

このような問題意識を解決するために、今紹介した『Infrastructure As Code』、『SRE - サイトリライアビリティエンジニアリング』、『詳解システム・パフォーマンス』、『データ指向アプリケーションデザイン』などの、システム開発・運用の現場の経験を盛り込んだ上で体系化した書籍がある。 しかし、Webシステムアーキテクチャに必要な技術要素を網羅するためには，これらの複数の体系を組み合わせる必要がある したがって、どの体系がWebシステムアーキテクチャに必要かが自明でないという課題と、 既存の体系同士の関連性が自明でないという課題がある。

そこで、この研究では、Webシステムアーキテクチャの初学者が，経験による帰納的学習に加えて，体系からの演繹的学習が可能となることを目指す。 さらに、Webシステムアーキテクチャ分野で新しい技術を研究する場合に，体系から複数のアイデアの組み合わせを発見可能とする。 システム分野は、多数の既存知識を組み合わせることが前提となるため、既存の体系を無視して、新たに体系を組み上げることは、その知識の総量から現実的ではない。 そこで、既存の地図(体系)を描き、つなぎ合わせて、どの方向にどれだけ歩くと何にたどり着くかが分かればよい。 そのためには、次の手順で地図を描いていく。

  1. 地図の中心点をとる => 今回はyuukiの関心の中心点であるSRE、すなわち信頼性の制御を選択
  2. 既存の体系(基礎知識体系と応用知識体系)を地図に描く
  3. 地図の中心点からの関連性が不明であったり空白の領地を見つけてそれらを明らかにする

その結果、ソフトウェアアーキテクチャやネットワーク・プロトコル設計など隣の分野から、SREの中心点まで、どのような経路をたどり、どれぐらいの技術要素を超えた先に行き着くのかを知ることができる。

関連体系

Webシステムアーキテクチャに関連する体系として、伝統的な情報工学の教科書以外に、産業界における実践知をまとめた体系がこれまでに提案されている。

SRE(Site Reliability Engineering)

SREは、信頼性(Reliability)こそがあらゆるプロダクトの基本的な機能であると考え、信頼性を軸にこれまでの運用技術を1つの分野として確立した。 書籍2「SRE サイトリライアビリティエンジニアリング」では、信頼性の定義として、文献3の"システムが求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率"を採用している。 さらに、信頼性を定量的にSLO(Service Level Objective)として設定し、システムが求められる信頼性を達成しているかを四半期ごとなど定期的にチェックし続けることが推奨されている。 加えて、SLOと変更速度がトレードオフであることから、SLOを過剰達成せずに変更速度を向上させるために、エラーの発生量を予算消化に見たて、リスクのある変更を許容するエラーバジェットの考え方がある。 このような考え方からSREとは、コンピュータシステムの信頼性を制御し、変更速度を高める工学分野であると捉えることができる。

同書籍では、コンピュータシステムの信頼性制御するための基本要素として、次の6点が挙げられている。

  • モニタリング
  • インシデント対応
  • 変更管理
  • キャパシティプランニング
  • プロビジョニング
  • 効率とパフォーマンス

さらに、第3部にて次の図のようにシステムの信頼性をピラミッドとして組み立てることが提案されている。 モニタリングが最下層にあることから、信頼性の最も基本となるものはモニタリングであると解釈できる。 モニタリングは、対象を監視するというその特性上、対象となるシステムがある程度形になったのちに、始めて開始できる。 したがって、信頼性を構築するにはまず対象となるシステムの特性が明らかである必要があるといえる。

(Betsy Beyer, 2017, p108 図III -1サービスの信頼性の階層)

詳解システム・パフォーマンス

対象となるシステムは、Webシステムの場合は分散システムとなることがほとんどであり、Webシステムにおける分散システムは単一ホスト上のプロセスから構成される。 単一ホスト上の構成を理解するには、OSの原理とOS上で動作するアプリケーションのシステムモデルを理解する必要がある。 書籍「詳解システム・パフォーマンス」4では、OSおよびOSのコンテキストにおけるアプリケーションのパフォーマンス分析と向上手法が解説されている。

同書籍では、次の図のように、単一ホスト上のシステムソフトウェアスタックを整理した上で、オペレーティングシステム、アプリケーション、CPU、メモリ、ファイルシステム、ディスク、ネットワークの要素に分解し、システムのパフォーマンスモデルを解説している。

f:id:y_uuki:20190921181402p:plain (Brendan Gregg, 2017, p2. 図1-1 一般的なシステムソフトウェアスタック)

データ指向アプリケーションデザイン

Webシステムは演算指向のワークロードとデータ指向のワークロードの両方が求められ、とりわけソーシャルネットワークやIoTアプリケーションでは、多数の利用者やデバイスが生成する大量のデータを扱う必要がある。 書籍「データ指向アプリケーションデザイン」5では、分散システムにおける重要な3つの課題である信頼性，スケーラビリティ，メンテナンス性の3点に着目し、データ指向の分散システムを、ストレージエンジン、データを分散するときの配置手法、分散したデータの一貫性の担保手法などの観点で整理している。

Infrastructure As Code

Infrastructure As Codeは、ソフトウェア開発の実践知をITインフラストラクチャの自動化に活かすアプローチである。 書籍「Infrastructure As Code」[^4]では、Infrastructure As Codeのためのツールを次のように分類し、整理している。

  • ダイナミックインフラストラクチャプラットフォーム: インフラストラクチャの基本リソース、特に計算(サーバー)、ストレージ、ネットワークを提供、管理するために使われる。パブリック/プライベートクラウドインフラストラクチャサー ビス、仮想化、物理デバイスの自動構成/設定などが含まれる。
  • インフラストラクチャ定義ツール: サーバー、ストレージ、ネットワークリソースのアロケートや構成/設定を管理する。これらのツールは、高い水準でインフラストラクチャをプロビジョニング、構成設定する。
  • サーバー構成ツール: サーバー自体の細部を扱う。ソフトウェアパッケージ、ユーザーアカウントなど、さまざまなタイプの構成/設定が含まれる。Chef、Ansibleなどを含む。
  • インフラストラクチャサービス: インフラやアプリケーションサービスの管理を支援するツール、サービス。モニタリング、分散処理管理、ソフトウェアのデプロイなどがテーマになる。

関連体系のまとめ

これらの体系をすべて併せると、いずれもWebシステムを構成するために必要な知識の多くを網羅できる。 しかし、もともとこれらの体系はWebシステムアーキテクチャ向けではないため、単一の先行体系のみではWebシステムアーキテクチャの部分しかカバーできないことと、体系の一部が他の体系の一部と重複してしまうことが課題となる。

Webシステムアーキテクチャの分類

そこで、本研究では、Webシステムアーキテクチャを単一の体系として扱うために、関連体系を基にして、Webシステムアーキテクチャを構成する散らばった要素技術を整理し、新たな分類を提案する。 先行する各種体系から、Webシステムアーキテクチャを構成する大きなカテゴリを、次の4点に分類できる。

  • (1) アプリケーションの実行環境の構成手法: アプリケーションやミドルウェアが動作するための環境構築。ITインフラストラクチャなどとも呼ばれる。ネットワークルーティング、共有ストレージ、サーバープロビジョニング、コンテナ仮想化技術などを含む。
  • (2) 単一ホスト上のアプリケーションの構成手法: OSが提供する各種機能を利用し、アプリケーションを構成する手法。Webサーバアーキテクチャ、データベースのストレージエンジンなどを含む。
  • (3) 分散システムとしてのアプリケーションの構成手法: 可用性、スケーラビリティを確保するために複数のミドルウェアを組み合わせ、アプリケーション構成手法。3層構成、データベースの分散構成、マイクロサービス、サーバーレスアーキテクチャなどを含む。
  • (4) 構成されたアプリケーションの信頼性制御: 実行環境の上に構成されたアプリケーションの信頼性を制御し、運用するための手法。モニタリングなどを含む。

これらの分類は、それぞれが独立しているわけではなく、互いに関連している。 例えば、(4)の信頼性を制御するために、システム管理者がキャパシティプランニングを行うとすると、現在のキャパシティ消費量とこれまでの変化を知るためにモニタリングが必要となり、モニタリングをするためには、時系列データを格納するためのデータベースが必要となり、(2)と(3)の知識が必要となる。さらに、キャパシティプランニングの結果にしたがって、キャパシティを増減するためには、(1)の知識が必要となる。

今後の課題

まず、提案する体系を利用したときに，学習可能な範囲を明らかにする必要がある。 ソフトウェアアーキテクチャなどの情報工学の分野との関連性を明らかにする。 今回はWebシステムにおけるバックエンド層に着目したが、ブラウザアプリケーションなどのフロントエンド層との区別と関連性を明らかにする。 また、DevOpsに代表されるカルチャーや組織体系との関連性を明らかにする。

スライド

書誌情報

  • 著者: 坪内佑樹(*1)
  • タイトル: Webシステムアーキテクチャの地図を描く構想
  • 所属: (*1) さくらインターネット株式会社 さくらインターネット研究所
  • 研究会: 第5回Web System Architecture研究会

参考文献

  1. Kief Morris 著, 宮下剛輔 監訳、長尾高弘 訳, “Infrastructure as Code――クラウドにおけるサーバ管理の原則とプラクティス”, オライリー・ジャパン 2017.↩

  2. Betsy Beyer et al.編, 玉川竜司 訳, 澤田武男,et al. 監訳, “SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム”, オライリー・ジャパン, 2017.↩

  3. Patrick O'Connor, Andre Kleyner, Practical Reliability Engineering, Wiley, 2011.↩

  4. Brendan Gregg 著, 西脇靖紘 監訳, 長尾高弘 訳, “詳解 システム・パフォーマンス”, オライリー・ジャパン, 2017.↩

  5. Martin Kleppmann著, 斉藤太郎 監訳, 玉川竜司 訳, “データ指向アプリケーションデザイン――信頼性、拡張性、保守性の高い分散システム設計の原理”, オライリー・ジャパン, 2019.↩