2020年代を生き抜くWebアプリケーション基盤の私的整理

Webアプリケーションを動かすためにはどうしてもCPU、メモリ、ストレージなどが必要です。
せっかく作ったWebアプリケーションを誰かに使ってもらうためにはインターネットで公開する必要があります。
そして2020年現在「Webアプリケーションを動かして公開する」ためのプラットフォーム(XaaS)が何種類も存在します。

その何種類も存在するXaaSはそれぞれ名称はもちろん機能や使い方も異なり、Webアプリケーションを開発する私たちは仕様と特徴を理解しながら一定以上のレベルで使いこなしていくことを求められます。
XaaSの「仕様と特徴」は例えば私たちが日常的に使う白物家電や調理器具や交通機関などと比べると圧倒的にバラエティが豊富でその分学習に時間が必要なように見えます。

最近はそういうことをグルグル考えているので自分自身の整理として言語化を試みます。
なお所属企業の業態や領域を主にした話ではなく、あくまで私個人の”ステ振り”の話です。

また特定の企業やプロダクト、あるいは思想を否定するものではありません。
あくまで私個人の志向と落とし所だと捉えていただけると幸いです。

私の立場

XaaSの利用者である

AWS, Azure, GCPなどを対価を払って使う側です、提供する側ではありません。

主にWebアプリケーションの企画運営事業者である

大抵の場合において受託や請負の立場ではありません、また「設計が定まっている状態で実装のみ」という機会もありません。
事業の成績が自分たちの待遇に直結する立場です。
またWebアプリケーション以外のソフトウェア開発について本記事では触れません。

主に中規模以下のWebアプリケーションに携わっている

この記事では複数リージョンにまたがったり高トラフィックなWebアプリケーションを想定していません。

主にITエンジニア職である

以下いずれも大したことはできませんが一通り行う機会があります。

  • インフラ設計/構築
    • ネットワーク
    • OS/パッケージ
    • ミドルウェア
  • Webアプリケーション開発
  • Webデザイン/制作
  • プロモーションやイベントの企画/制作/運営
  • システム運用/セキュリティ対策
  • その他折衝/調整

Production environment

本番環境について自身の「ステータスポイントの割り振り方と理由」をレイヤーの低い方から高い方へ記載します。

オンプレは卒業する

  • もはやIaaSの外でオンプレサーバーが必要になる機会は極めて稀だと考えています
  • もしDropboxやBoxみたいなアプリケーションを創業できて大当たりしたら考えます
  • 物理サーバーや物理スイッチ、楽しいですけどね

本番のコンピューティングはDocker(≒コンテナ)ホスティングに寄せる

  • Googleという世界最大級のコンテナ化成功例があるわけですし、そうそう外さない考え方だと信じてます
  • Dockerはコンテナの仕様として捉えています
    • もしDockerが廃れたら他のコンテナに移住します
    • コンテナの考え方はそのまま転用できるの損しないはずです
    • 特にnamespaces, cgroupsあたりはこの先仮に実装が変わることがあっても考え方はそうそう変わらないと思っています
  • Dockerエコシステムの肩に乗る
    • 私もDocker以前には細々とZone(Solaris)やLXCなどを試みたことはありますが運用体制は作れませんでした
    • エコシステムは偉大です、先人に感謝しつつ全力で乗っかります
  • k8s他を使ってスケールもしやすくなりました

本番のデータ永続化はマネージドサービスに寄せる

  • RDBMSのチューニングで価値を出せる機会は相当に減ったと感じます
  • ファイルシステムのチューニングで差を出せる時代でもないです
  • 可用性に関しても総合的な数値で各IaaSを超えることは困難です
    • マネージドサービスを使えばRAIDやDRどころではない可用性がすぐに実現できます
    • そもそも個人やIaaSを作っていない私企業が世界各地にIDCを持ちF/Oの仕組みを構築することは相当に困難です

その他マネージドサービスに寄せたいこと

  • Logging、モニタリング、メッセージング、ビルドパイプラインなどなど
  • 機能として枯れていて仕様がコモディティ化してるものはマネージドサービスに寄せていきたいですね

認証はSaaSに寄せていきたい

  • 寄せたいと言いつつ諸事情で自前実装する機会はまだまだあります
  • 認可は当面実装必要そうだと考えています

IaaS(VM)の使用は極力避け、GPUなど特殊要件に限定したい

  • そもそもGPUなどが必要になる状況は稀ですが、あります
  • GPUなども近いうちにコンテナ化できると期待しています

FaaSは要件が極めて合致した場合に使う、PaaSは慎重に導入する

FaaS/PaaSに関して私の姿勢は似ており、やや保守的な考えをしている自覚があります。
以前にも似たような記事を書いていますが、以下のような課題に直面し、当時よりもさらに慎重になりました。
この考え方には私が特定のPaaSに強い思い入れがないことも影響しています。

FaaS/PaaSはIaaSやコンテナより抽象度が上がり独自機能が増えるため適切に導入すれば開発と運用のコストを大きく下げることができます。
一方で以下のような課題も抱えています。

  • 要件は常に変わる
    • プロジェクト発足時には不要だったxがプロジェクト後半になって必要になることはよくあります
    • プロジェクト要件の変化は外的要因によることが少なくなく予測不能です
      • 仮にプロジェクト発足時にはTwitterにCardを表示する機能がなかったとして、プロジェクト終盤でTwitterにCard機能ができたら表示したくなるのが人情です
      • エンタープライズの要件が固定される場合もあるかもしれませんが、これは変わらないのではなく変えないのだと捉えています
    • FaaS/PaaSが抽象度高く実装量が少ないのは自由度が制限されている対価です、途中で必要になった特性がFaaS/PaaSではかなり無理をしないと手に入らない場合は現実としてあり得ます
  • Debugに時間と費用がかかることがある
    • FaaS/PaaSは大前提としてローカルでは動きません
    • エミュレーション/シミュレーションの方法も増えてきてはいますが、実際のFaaS/PaaS上でしか再現できない問題も多く存在します
  • プラットフォームごとの差異と学習コスト
    • 例えばAWS Lambda向け実装とCloud Functions向け実装の差分は、Amazon ECS向けコンテナとCloud Run向けコンテナの差分より大きくなるでしょう
  • ランタイムや仕様変更時のキャッチアップコスト
    • 例えば機能の廃止やあるいは半年ほどソースコードにアクセスしない間にプラットフォームの細かな仕様が複数変わったりSDKが更新されていた場合、追従するコストがとても大きくなることがあります
    • ごく少数のWebサービスやソースコードリポジトリをメンテナンスするのであればあまり問題にならないかもしれません
  • 要件との合致度
    • 特にPaaSに関して、要件とPaaSの機能が合致しないことはそれなりにあると感じます

もちろんFaaS/PaaSを一切使わないわけではありません。
繰り返しますがFaaS/PaaSへの否定でもありません。
要件が合致すればぜひ使いたいですし、実際に慎重に導入した結果FaaS/PaaSならではの利益を享受したこともあります。

Development environment

前述の本番環境に合わせた開発環境を記載します。

本番の想定に合わせて開発環境もコンテナに寄せる

  • Docker Composeでアプリケーション実行環境とミドルウェアをまとめて起動する方法を好んでいます
  • ミドルウェアは極力オフィシャルなDockerイメージをそのまま使います
    • MySQL、Redis等
  • 開発用のDockerfileは整理して統一しようとしています
    • https://github.com/mazgi/dockerfiles
    • 多少fatにはなりますがプロジェクトごとに少しずつ異なるファイルを管理するコストとのトレードオフとして受け入れています

DockerのホストはLinux

DockerはLinux以外のOSをホストとして実行するとストレージの性能が大きく下がります。
これはDockerがLinux Kernelに依存しており、Linux以外をホストとして実行する場合でもLinux VMを介していることが根本的な理由です。
従ってこの状況は当面変わらないと考えており、愚直に開発用のホストOSとしてLinuxを用意しています。

LinuxホストをWebアプリケーション開発に使う上での困りごとはAdobe CCやOfficeなどのいくつかのアプリケーションが動作しないことです。
しかしこれはmacOS/Windows上でVSCodeを起動しRemote SSH機能でLinuxホストに接続することで対応しています。

私自身の裁量で開発環境を用意できる場合はLinux VMを用意し、その上Dockerコンテナを起動しています。
NVMe接続のSSD等、ストレージI/Oが十分に早ければVM上であることは問題となっていません。

開発用PCの調達に制約がある場合でもLinux開発環境を導入させていただいています
これはマネージャーや関係各所のサポートによるものでありがたい限りです 🙏

Linuxが起動する開発用PCの調達が難しい場合にはIaaS上にLinux VM立てて開発環境として使うことも一応可能です。

Not to do

XaaSに限らずすべての技術トレンドを追いかけ理解することはできません。
ここでは私があえて自分のスコープから外していることもいくつか書き出してみます。

XaaSの内部を自習しない

IaaSにせよPaaSにせよ一人の利用者の立場では”中の人”とは大きな情報格差があります。
利用者でしかない以上、内部構造についてはごく一部の例外を除いて推測することしかできません。
そのためドキュメント読んでわからないことは素直にSAの方に伺うようにしています。

所属企業などでエンタープライズサポートを契約してる場合はSAの方と積極的にコミュニケーションを取ると色々教えていただけます。
利用者(私)は時間が短縮できるし、SAの方は少なくとも間接的には成績に繋がるはずですし、XaaS各社さんは売り上げに繋がるので三方よしです。

またXaaSの内部は利用者から伺い知ることができませんが、一方でXaaSの多くはAMD64アーキテクチャ, Linux(Azureの場合はWindows), HDD/SSD, TCP/IPなど私たちが触れることができる技術を採用して提供されています。
もちろん規模や性能、効率化において個人や一般の私企業では到底なし得ない技術レベルが発揮されていることも事実ですが、これらの基本的な技術の理解はXaaSを使う上でも役立ちます。

XaaSの性能チューニングを頑張らない

そもそも頑張れる範囲が決まっています。
ベアメタルの主要なチューニング要素は、XaaSではブラックボックスまたは課金要素のどちらかです。

例えば物理環境でストレージやネットワークのベンチマークを取ったことがある方は、ベアメタル→VM→IaaSの順で関与できない部分が増え数値の揺らぎが大きくなった経験をお持ちかもしれません。
高トラフィック環境などで悩ましいことはありますが、プラン選定と可能な範囲のウォームアップなどで落とし所とするのが現代のチューニングでしょう。

Dockerfileのチューニングは後回しにする

少なくともPoC〜サービス初期ではDockerfileのチューニングはあまり必要ないと考えています。
むしろポータビリティの維持やCI/CDしやすい構成を工夫した方が開発が円滑に進むと感じています。

Dockerfileのチューニングは大規模サービスに育ったら専任者(自身の場合もある)をアサインして頑張ることにしています。
ただしあまりにもfatなまま開発規模を大きくしてしまうと、後々容量やビルド時間が大きな問題となってしまうのが難しいところではあります。。

セキュリティも頑張りすぎない

セキュリティは常にトレードオフです。
セキュリティを強固に固めることには際限がありません。

そして「安全とは言い切れないが便利なもの」は世の中にたくさん存在し私たちの生活を支えてくれています。
ブラウザでのJavaScript実行やiPhoneのAirDropなどは身近な例でしょう。
(信じられないかもしれませんが「JavaScriptをOffにすることを推奨」される場合がありました)

その他便利な大抵のものや機能はセキュアではない部分を含んでいます。
そもそも「全ての状況で安全」なものなど存在しないのではないでしょうか。
個人的にはこれは毒と薬の関係にも似ていると感じます。物理世界には適量なら薬でも過ぎれば毒になる物質ばかりです。

もちろん「HTTPS不要、HTTPで充分」とか「フォームから受け取ったスクリプトやSQLをそのまま実行」という話ではありません。
バランスが大事です、そしてバランスを取ることは常に難しいです。

That’s all from me.

2025年くらいまでは前述のような方針で生きていけるといいなと淡い期待を抱いています。

とても残念な事実として可処分時間は短く自身の能力は限られています。
これらの割り振りを工夫して少しでも多くの成果を成していきたいところです。