マネージドへ渡すとき一緒に渡るもの
一言でいうと
IaaS・PaaS・SaaSは技術的な分類ではなく、どこまでを他人に任せるかの目盛りです。上に行くほど楽になり、同じだけ、統制権を失います。
なぜ必要なのか
「RDSを使うか、EC2に自分でインストールするか」は、ほとんどすべてのプロジェクトが一度はする質問です。答えは「何がより良いか」ではなく、何を手放せるかで分かれます。
| IaaS(EC2に直接) | PaaS(RDS) | |
|---|---|---|
| バージョンの選択 | どのバージョンでも | 事業者がサポートするバージョンだけ |
| 拡張機能 | 何でもインストール | 許可リストにあるものだけ |
| OSアクセス | rootで何でも | なし。シェルがありません |
| パッチ | 自分たちで計画 | メンテナンスウィンドウに事業者が実施 |
| 障害調査 | ログ・プロファイルが自由 | 公開されたメトリクスとログだけ |
| 運用人員 | 必要 | ほぼ不要 |
| コスト | たいてい安い | たいてい高い |
OSアクセスがないという項目が、実務でいちばん痛いところです。PostgreSQLの拡張1つを使えなかったり、カーネルパラメーターを触れなかったりして、マネージドを諦めるケースが実際にあります。そのため、決める前に「今、サーバーで何をしているか」をリストに書き出してみるのがよいです。
どう動くのか
コンテナはどこにあるのか
IaaS ─ VM ─ 컨테이너(직접 운영) ─ 관리형 K8s ─ 컨테이너 서버리스 ─ PaaS ─ SaaS
(EKS/AKS/GKE) (Fargate/Cloud Run)
マネージドKubernetesはコントロールプレーンだけを預けます。ワーカーノードのOS・kubelet・CNIは、依然として自分たちの担当であることが多く、これを知らないと、「マネージドなのに、なぜノードのパッチを自分たちがやるのですか」という質問が出ます。
サーバーレスは何と引き換えか
関数単位の実行(Lambdaなど)は、運用の負担がほとんどなくなる代わりに、制約が付きます。
- コールドスタート。しばらく呼び出しがないと、最初のリクエストが遅くなります。
- 実行時間の上限。長い処理は動かせません。
- ステートレス。ローカルのディスクやメモリに、何かを溜めておけません。
- ベンダーロックイン。イベントモデルとランタイムが、事業者ごとに違います。
トラフィックが不規則で、処理が短ければ圧倒的に有利ですが、安定した負荷で処理が長ければ、かえって高くつきます。
ロックイン(lock-in)を値段として計算する
マネージドを使うと、その事業者に縛られます。これを無条件に避けようとすると何も使えませんが、値段を知らずに使うと、あとで移行コストが爆発します。判断基準は次のとおりです。
- 標準の上にあるか。PostgreSQL互換のマネージドは移しやすく、独自APIは難しいです。
- データがどれだけ溜まるか。データが大きいほど、移行が高くなります。
- 代替手段があるか。別の事業者に、同じ性格のサービスがあるか。
「ロックインされないようにする」よりも、ロックインされる代わりに何を得るかを知っていることのほうが、役に立つ姿勢です。
現場での姿
- マネージドDBに移したら、必要な拡張がなくて元に戻しました。事前の確認漏れです。
- サーバーレスでバッチを動かしていて、実行時間の上限に引っかかりました。処理の性格が合っていませんでした。
- マネージドK8sなのに、ノードのCVE対応を自分たちで行いました。境界を誤解していました。
責任の境界を文章で書いておく
モデルを選ぶことより、もっと頻繁に事故を起こすのは、境界の誤解です。「マネージドだから勝手にやってくれるだろう」と放置していた項目が、実は自分たちの担当だったという場合が大半です。そのため、導入のたびに、次の項目が誰の担当かを1行ずつ書いておくとよいです。
| 項目 | 誰が行うか |
|---|---|
| 物理機器とハイパーバイザー | 常に事業者 |
| ゲストOSのパッチ | IaaSは自分たち、PaaSは事業者、マネージドK8sのノードはたいてい自分たち |
| アプリケーションの脆弱性 | 常に自分たち |
| アクセス権限の設定 | 常に自分たち |
| データの暗号化の有無 | たいてい自分たちが有効にします |
| バックアップの保管期間と復旧テスト | 事業者がバックアップを作っても、復旧テストは自分たち |
| アベイラビリティゾーンの配置 | 自分たちが決めます |
表の中で最もよく裏切られる行が、バックアップです。マネージドデータベースが毎日バックアップを作ってくれるという事実を根拠に安心しますが、そのバックアップで実際に復旧できるか、保管期間が自分たちの必要なだけあるか、そしてアカウント自体が誤っていたときにも残っているかは、すべて自分たちが確認すべきことです。バックアップがあることと、復旧できることは、別の事実です。
権限も同じです。クラウドで起きる事故の大きな部分が「設定を間違えたこと」で、この領域は、どのモデルを選んでも自分たちの担当として残ります。上に行くほど減るのは、運用の負担であって、責任ではありません。むしろ、マネージドを使うほど、自分たちが統制できる手段が設定だけになるので、その設定1つ1つの重みが増します。そのため、マネージドに移すときは、手がかからなくなる分、余った手を設定のレビューと復旧テストに使う必要があり、その時間を確保しておかないと、削減した運用時間が、そのまま危険に変わります。
次に見ること
マネージドサービスの値段がどこから出るのかを、料金表ではなく運用時間で見ます。