アーキテクトコラム、はじめました

みなさんはじめまして、NRIデジタルの松村です。新規システムや大規模改修などの案件でアーキテクチャデザインからその後の開発／構築をリードしたり、技術でビジネス価値をあげるためのコンサルティングをするようなお仕事をしています。

誤解を恐れずに言うと、アーキテクトというのは、選択するお仕事だと思っています。システム的な要素・特性はもちろんのこと、事業としての要件やこれからの発展性、開発陣やステークホルダのこだわりなど、様々な観点を元に選択し、決めていく。その得失を、クライアントをはじめとしたステークホルダに説明し、進むべき方向を形作っていく。とてもやりがいがありますが、一方でその決断が後々に広い範囲で影響してくる、責任重大なお仕事でもあります。

私がいくつかのアーキテクチャデザイン経験から理解したのは、プラクティスはあれど、アーキテクチャに求められるものはとても多くてケースバイケースになる、ということです。そのため、「この場合はこれでいけばいいよ」というのは決めることができません。たとえば、過去に経験した案件で、開発陣の経験と製品サポートの構成からとあるRDBプロダクトを採用する方針で進めたところ、クライアントから「弊社はその会社の製品は採用しないことにしている」という指示を頂き、作り方から全部ひっくり返ったことがあります。

ではどうすれば選択できるようになるのかというと、様々なケースを見聞きして、新しい観点や考え方をひとつずつ身につけていくことではないかと思います。

そういった想いから、私が見聞きしてきた経験を元に、テーマを決めてその関連で考えてきたことをつらつらと書いてみよう、とこのコラムを始めてみました。一般的なアーキテクチャに関する検討・考察は数多くの書籍・ブログがありますのでそちらにお譲りします。当コラムを通じて、みなさんの「考える力」をつける一助になれれば嬉しく思います。

みなさんが関わりの薄いところは少し前提知識が必要になるかもしれません。そういう時は、できるだけキーワードをちりばめながら進めますので、キーワードをGoogle先生に聞きながらゆっくりと読んでみて下さい。

WebとAPIとサーバレスと：何が起きているのか

さて第一回の今回は、まずは王道どころということでWeb/APサーバ（Webサーバ、Applicationサーバ）の選択です。簡単にトレンドのおさらいから入りましょう。

2000年前後のインターネットバブル期に、インターネットのネットワーク機器、通信網などの費用が劇的に下がり、急速に普及しました。これに伴い、Webブラウザの機能が高度化し、ビジネスの領域においても今まではクライアント－サーバ方式で個別クライアントを開発していたものを徐々にWebブラウザに置き換えるようになりました。現在著名なECサイトもこの頃に生まれたものが多く、システム開発におけるWebシステムの割合が急速に拡大しました。

Webシステムでは、ブラウザは描画だけを担当するため、どういう画面を作るのかといったUI部分から、ロジック、データまでを全てサーバ側で処理・提供します。しかし、これら全てを一体として開発すると複雑化しやすく、修正時の範囲も多岐にわたります。そのため役割を分割するアーキテクチャが提唱され、プレゼンテーション、アプリケーション（ビジネスロジック）、データ、の３層に分ける考え方が主流となりました。これがWeb３階層です。３つに役割を分けることで、それぞれの変更に対する影響を小さく、わかりやすくしようという意図です。
当時であればApache(HTTP)／tomcat／MySQL、といったあたりのプロダクトが該当するでしょう。プレゼンテーション層は、当時は静的なページが中心だったためこのような呼び名になっていますが、今だとコンテンツや(URL)ルーティングが中心になるかもしれません。この頃は、「どの層にどのプロダクトを採用するか」や、「間にキャッシュを挟むか」といったあたりが主要な選択要素でした。

ところが、徐々に画面に動的な要素が増えてきます。たとえば、ECにおけるカート機能は、ユーザがカートに入れている商品の一覧を出しますが、これはユーザによって異なりますね。こういった動的要素を誰がどこで制御するのか、ということが課題になります。

１つは単純で、アプリケーション層で制御する、です。この流れにより、Web/AP一体型のプロダクトやサーバ構成が進みました。ただし、徐々にプレゼンテーションとアプリケーションの間が不明瞭になってきます。プレゼンテーション層を変更しなくても、アプリケーション層が変更になることで想定と異なるデータが渡され、画面表示が崩れたり出なくなるということがよく起こるようになります。
もう１つが、プレゼンテーション層で制御する、です。ブラウザの機能は日増しに膨らんでゆき、javascriptの発明と標準化により加速度的に高機能化が進みました。そのため、プレゼンテーション側が、必要な処理／要素を要求し、アプリケーション側は処理／要素の単位でI/Fを用意、提供するという考え方が出てきました。こうしてアプリケーション層でAPIを提供する（WebAPI）という構図ができました。ただし、プレゼンテーション層とアプリケーション層の間にWebという不安定なネットワーク層を挟むことで、考慮が必要な問題も増えました。

また、スマートフォンとそのアプリの普及により、サーバサイドのAPI化に拍車がかかりました。プレゼンテーション側をSPA(Single Page Application)などの構造にしておけば、サーバサイドのAPIはWebでもアプリでも共通的に使用することができるためです。これは、元々Web３階層で考えていた「プレゼンテーション層とアプリケーション層が独立し、お互いの影響を小さくする」ということに通じますね。

サーバサイドがAPI化すると、Web/AP一体型と比較して、APIごとの機能というのは比較的小さなものになりやすくなります。また、ユーザ個別の振る舞いをクライアントサイドに寄せることにより、サーバサイドで持たなければいけない「ユーザ個別情報（≒セッション情報）」が少なくなります。（正確には、なくしてもいいのですが、セキュリティ的な観点で一部の情報は保有する必要があります）
セッションが必要な場合は、これをAPサーバのメモリに保持することが多いです。これをサーバ間で共有するのは手間（＝共有キャッシュやAPクラスタなどの構築）がかかります。そうすると、同じAPサーバを使い続けたくなります。カートが時々消えてしまうなんて、そんな信用できないお買い物籠は使いたくないですからね！
一方、セッションが不要になってくれば、同じサーバを使い続ける必要はありません。極端な話、毎回まっさらなサーバが立ってもいいわけです。それならば、別に壊れても新しいサーバを用意すればいいわけで、丁寧に面倒を見る必要がなくなります。むしろ新しいものの方が、使い続けることによる問題（メモリリーク、ディスク溢れ、などなど）を引かずにすむという側面もあります。そうなると、別に他の人に管理を任せてもいいよね、ということで、サーバレスアーキテクチャによるサーバ管理からの開放を得ることができます（注：サーバレスには様々な文脈がありますので、あくまでこれは利用したいニーズの一例です）。なお、ここではサーバレスという単語は「コンテナマネージャを自分で管理しない」という意味で使用しています。この枠組み内には、コンテナマネージャをサービス側で管理しているようなサービスから、PaaS、FaaSなどを含みます。（SaaSは文脈が異なるため、原則として対象外です）

こうして、我々はWeb３階層時代の単純なプロダクト選択ではなく、プレゼンテーション層とアプリケーション層の配置、更にはセッションの管理とサーバの扱い、という豊富な選択肢、言い換えると問題を手に入れたわけです。（選択肢が増えるということは必ずしもいいことではありません。詳しく知りたい方は「選択の科学」という本を読んでみて下さい。もちろん、いい面もありますよ。）

WebとAPIとサーバレスと：Web/APサーバ系の選択

え？　「新しいものがいいんじゃないの」ですって？　一理ありますね。でも、あくまで「一理」です。特定のプロダクト、たとえば、Apache httpを利用する場合、2.2系と2.4系であれば、絶対に2.4系を利用するべきです¹⁾ただし、互換性への懸念や最新が正式リリースされていないなどの場合を除く。エンタープライズの場合はバグの枯れ具合から最新版を避ける場合もありますが、最近はプロダクトリリースまで／からの品質向上が著しく早いこと、そもそもの最新版からサポート終了までの期間が短くなっていること、などから、やはり最新版を利用する傾向が強いです。これは、プロダクトのEOL²⁾End Of Life。サービス提供終了。オープンソースの場合は更新終了やサポート終了の意味。EOSL(End Of Service Life)とも言うは最新版が最も長いこと、バグへの対応などが早いこと、などが理由です。
しかし、アーキテクチャはそうではありません。新しいアーキテクチャが出てくる主な理由は、「今までの方法では解決が難しい問題を解決する」ためです。たとえば、上記の流れでいうと、「ユーザごとの動的な情報を扱いたい」→「ブラウザ＋API」というようなものですね³⁾大事なので何度も言いますが、あくまで一例です。鬱陶しくなるので脚注化しました。すると、逆説的に、静的な要素を扱う場合はAPI化する必要がないということです。このように、やりたいことに応じて適切なアーキテクチャを選定するというのが正しいアプローチです。間違っても、「最近マイクロサービスが流行っているので、ちょっと採用してみようかな」のような、土佐日記のようなノリで選ばないように注意してください。そういう場合は、大抵旧来のアーキテクチャの方が適切です⁴⁾これ、ほんと。新しいものの選定はリスクと背中合わせです。その分のリターンは当然ある場合が多いですが、リスクを適切に理解できていない場合は、大抵はリスクがリターンを上回ります。あくまで経験上の感覚ですが。

では気を取り直して、どのように選定するかです。選定根拠は、大きく分けて２種類になります。システム構成的根拠と、その他の付帯的条件です。どちらを重視するのかはプロジェクトごとの判断になります（ちなみに、ここだけの話ですが、システムインテグレータでは付帯的条件の方が重視される傾向があります。詳細は後述）。まずは王道のシステム構成から説明します。

システム構成的根拠

最もシンプルなのは、ホームページのような、静的なコンテンツだけを扱う場合です。この場合は原則として一体型を選択します。もう少し正確に言うと、APサーバが不要です。静的コンテンツだけであれば、サーバを立てずに公開する方法も最近は用意されています。パブリッククラウド各社が提供する「静的ウェブサイトホスティング」と呼ばれるものがそれにあたります。たとえば、AWS、Azure、Google Cloud などで利用可能です。これらは、後述する、プレゼンテーション層のSPA化においてコンテンツを配置する場所としても使用できます。

次に、「そう大したことないサイト」です。実はこれが一番難しいです。なにせ、何でやってもそれなりに作れるからです。そのため、大抵は付帯的条件を重視して選定します。どういうことかというと、例えば生産性。Ruby on Rails が一時期一世を風靡しましたが、これはCoC⁵⁾Convention over Configuration。設定より規約。いわゆる「暗黙的了解」を作ることで、開発者の開発量を圧倒的に削減する手法。習熟した開発者の生産性は非常に高くなる一方で、初学者が適切に理解できるようになるまではそれなりに大変、という傾向があるを最大限に活用することで、少ない実装量での実現を可能にしています。フレームワーク生産性を重視した、Web/AP共にサーバ側のアプローチになります。ただし、このあたりになると開発者の慣れによる生産性が大きな要素を占めてくるので、何で作りなれているのか、という「付帯的条件」側の方が支配的になります。ただし、Web開発フレームワークというのは、歴史が長い方が多く開発され、高機能である傾向があります。また、プレゼンテーション層をクライアント側に置いた場合、アプリケーション層と別のフレームワークとなる場合が多いため、複数のフレームワークを扱うこととなる場合もあります。これは学習コストという観点では高くなります。

スマホとPCの両方で使いたい場合。この要件は特にここ10年くらいでどこでも必要とされてきているのではないでしょうか。実現方法は大きく分けて２つあります。１つは、どちらも同じものを使う方法。これは、レスポンシブデザインなどの技術により、「コンテンツは一緒だが、表示端末に合わせて表示方法を変更／最適化する」ということができるようになってきました。もう１つは、別のものを作る方法。これは昔はPC版とSP版と呼ばれるような２種類のサイトを作ることが多かったですが、最近はアプリを別途作るほうが多いかと思います。このうち、アプリを別途作る方式を採用するのであれば、SPAなどのクライアントサイドでプレゼンテーション層を実現する方式を採用し、サーバサイドはアプリケーション層としてのAPI開発を行う方がよいでしょう。これは、スマートフォンアプリとAPIレベルで共通化することでロジックの集約が可能となるからです。
ちなみに、もちろん、これら（レスポンシブWeb＋アプリ）を混合することも可能です。ただし、特別な理由がない限りはお勧めしません。なぜなら、アーキテクチャパターンは可能な限り、少ない方がよいからです。これはアーキテクチャ選定の原則になります。なぜなら、非機能系の考慮点（性能、セキュリティ、耐障害性など）はアーキテクチャパターンごとに検討する必要があるからです。そのため、多少の不便であればパターンを集約することをお勧めします。作るときはよいかもしれませんが、運用後に問題が出てきた場合の対応量が大幅に異なります。

ユーザレスポンスを極力高速化したい場合。SPAの採用メリットとして語られることが多い⁶⁾ただし、SPAは初回ロードのコストが高いため、どこに着目するかにもよるですが、CDNをはじめとしたキャッシュの活用などを考えるとこれだけでアーキテクチャを選定するべきではないです。クライアントとのデータのやり取りを最小に抑えること、データを（キャッシュを含めて）できるだけクライアントの近くに配置すること、というのが基本戦略になります。

大量のアクセスが想定される場合。特にボラティリティが高い⁷⁾上がったり下がったりという変動が激しいこと。アクセスの場合は、アクセスが集中したりまったく来なかったりという変動幅が大きいこと場合。この場合は、なるべくサーバレスに寄せる方が望ましいです。ペットではなく家畜⁸⁾乱暴に言うと、サーバ１台ごとにおける差異をつけず、異常がある場合は修復ではなく除去と追加をする、という考え方。 http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/に最も近いパターンであり、従来のサーバ型の考え方でこれを対応しようとすると、無駄なノードを抱えるコストだけではなく、非常に多くのキャパシティ設計上の考慮が必要になり、大抵は割に合いません。ゲーム系はもちろんのこと、最近ではＥＣにおける特売などもこういった構成をとるケースが増えてきています。

付帯的条件

開発体制とケイパビリティ。ある意味これが最も大きな付帯条件といっても過言ではありません。非常に大きな開発プロジェクトの場合を除き、学習コストというのはプロジェクトにおいてとても大きな要素になります。
この要素は２つに分解できます。１つは、現有体制におけるケイパビリティ。開発メンバとして誰が入るのか。およびその人たちはどういう開発をしてきたのか。技術はもちろん、プロジェクトの進め方なども要素になります。会社として保有している標準的な進め方やチェックリストなどもケイパビリティに含まれます。これは、特定のフレームワークや部品群に関するものもあれば、Web３階層アプリケーションの開発、などの広範囲に適用できるものもあるでしょう。これらは共通部品の開発や標準化（コーディングルールなど）の制定コストを下げてくれます。もう１つは、調達のケイパビリティ。現有体制で不足するケイパビリティについて、外部（社内／外問わず）で補えるのか、そのコネやコスト・時間はあるか⁹⁾特に社外調達では、コネ、つまり今までの組織や個人としての関係性がない場合はコストか時間、もしくはその両方がかかります。というのは、新規外部調達先の技術的／マネジメント的能力や文化的背景を見極めるのはなかなか難しいからです。これが適切にできない場合はプロジェクトの後段で想定した成果物と現在の成果物の食い違いが大きくなります。それを防ぐためには、あらかじめ小さい仕事やプロトタイピングで確かめる、（期間とコストの）バッファを持つ、リスクヘッジで複数に依頼する、などが必要となりますが、いずれもコストや時間がかかります。、といった要素です。
ケイパビリティは全ての要素に関わってきます。たとえば、Ｗｅｂ３層構成でよく利用されていた、Ａｐａｃｈｅ／Ｔｏｍｃａｔ構成だとすると、ＯＳ層の設計／設定、Ａｐａｃｈｅ設定、Ｔｏｍｃａｔ設定、Ｊａｖａサーブレットエンジン上での開発、と、技術だけだとしても最低でもこれくらいは必要になります。全ての要素に対してケイパビリティが充足していなければならない、ということではありませんが、ケイパビリティが不足している部分は大きなリスクですので、先もっての検証やせめて有識者をアドバイザリに招く、重要な機能をそこにあてない、などの対策は行うべきでしょう。

インフラエンジニアがいない。昨今の、特にパブリッククラウド隆盛により、インフラエンジニアは必要不可欠な存在ではなくなってきました。では「必要ない存在」なのか、というと、全くそういうことはありません。むしろ、インフラエンジニアの領域をアプリケーションエンジニアが兼ね備えなければいけなくなってきた、という方が適切ではないでしょうか。たとえば、今までであれば何も考えずにユーザ情報をセッション領域に格納しておけばよかったのが、「インフラエンジニアが不要な」サーバレス構成にすることで利用できなくなります。セッション領域をキャッシュノードに退避させたら、キャッシュが揮発したときに異常な処理を起こさないような仕組みを作る必要があります。これはセッションを使う方式であればアプリケーションフレームワークが担保してくれていた領域を実装することになります（それも既存のライブラリを使えば解決するよね、というご指摘はごもっともですが、そのライブラリの適正性検証や「そこに考慮が必要になる」という意識は必要です）。こういった部分はインフラエンジニアやミドルウェアエンジニアが担保してきた領域です。
当たり前の話ですが、今まであった複雑性というのは、無駄なものがあったわけではありません。各サービサーはそれらの「共通的にやっておいた方がよいこと」をやっておいて隠蔽化することでサービスを高度化させていますが、それは中身がわからなくても安全に使える、というわけではありません。理解した人が使うと強力な武器になりますが、理解していない人が「使えてる」と、時に凶器に変わります。
とはいえ、いなくてもやらなければいけない場合もあるでしょう。そういう場合は、なるべくマネージドサービスを使用してください。先ほど「わからないで使うと危ない」と述べたばかりですが、それでもわからない状態で素のサーバを使うより100万倍安全です。セキュリティ観点だけで見ても、一般的なサーバに対する攻撃のかなりの割合はデフォルトで使用するだけで閉じてくれます。ただし、重ね重ねですが「だから安全」ではない、ということだけ注意してください。わからずに使っていると、例えばせっかく証明書ベースでしかアクセスできないSSH接続を簡単なパスワードでどこからでもアクセスできるように開放したり、というようなリスクを容易に踏むことになります。

ステークホルダの制約。意外と多い要件です。お客様が特定のプロダクト使用を前提／禁止している場合や、社内ステークホルダが特定のサービスに対して強く肯定的（使わないといけない）／否定的（使ってはいけない）な意見を持っている場合などがこれにあたります。その他の要件と折り合わない場合も多く、粘り強い交渉が必要になったりしますが、どうしようもない場合も多いため、代替案もあわせてもっておくべきでしょう。ちなみに、こだわりポイントを丁寧に確認することが地味に重要です。「ｘｘを使え、と言われたが、よく確認すると一部でも使っていればよいとのことだった」とか、「ｘｘはダメだ、と言われたが、実績がないことを心配されていただけだったので弊社実績（自部署実績）を説明すれば問題なくなった」などもよくあることのためです。

学習ニーズ。ケイパビリティのないものを避けていると、ケイパビリティが獲得できず、次の仕事にも繋がらない、という悪循環が起きます。そのため、あえてケイパビリティがない（そしてアーキテクチャ的にも使用必然性がない）場合でも、プロジェクトリスクおよびその後のメンテナンス負荷が少ない場合にチャレンジする、という観点もあります。この場合、適用対象がクリティカルになりそうな場合は安定したアーキテクチャへ変更して作り直す、という判断が必要になる場合もあります。

さいごに

いかがだったでしょうか。網羅的な記載ではありませんが、アーキテクトとしての考え方の一端に触れられたと思って頂ければ幸いです。アーキテクチャ選択は、上述のように、パターンを理解する以外にも、そのあたりの関連技術、構造、最近の動向などを押さえた上で、付帯的条件である、ステークホルダ関係、開発体制とケイパビリティなどを把握して判断する必要があります。

NRIデジタルでは様々なアーキテクチャ議論をしたい方など、一緒にチャレンジできる仲間を募集しています。採用の応募はもちろん、話を聞きたいなどの場合も含めてお気軽にご連絡ください。

また、自社システム／次プロジェクトでどのように進めていけばよいか悩まれている企業様のご相談もお待ちしております。お仕事の依頼はもちろん、「こういう話を聞いてみたい」「次に何をすればいいかわからない」などのご相談も可能です。遠慮なくお声掛けください。

それでは今回はここまでになります。次回をお楽しみに。（次回はもう少し短編になる予定です）