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 年くらいまでは前述のような方針で生きていけるといいなと淡い期待を抱いています。
とても残念な事実として可処分時間は短く自身の能力は限られています。
これらの割り振りを工夫して少しでも多くの成果を成していきたいところです。