はじめに
Webサーバ (主にWordPressの環境) のリリーススピードを加速するために様々なアプローチがありますが、最近、AWSで「Amazon Lightsail」を採用する選択肢が再注目 (再評価) されています。
AWSであればEC2やECS (Fargate) の採用が真っ先に思い浮かぶ中、なぜLightsailに向かう選択肢があるのかについてまとめます。
Amazon Lightsail を選ぶポイント
Lightsailにしかない特徴によってもたらされるメリットが多数あり、これらのメリットが企業にLightsailを選ばせる動機となります。
1. WordPressの初期環境構築までの時間が短い
以下の画面が最も分かりやすく特徴を表しますが、EC2やECSのコンソールよりも遥かに簡単で、選択項目も少ないため、WordPressインストール直後の初期画面を表示するまでを素早く構築できます。
さらに、この選択によってWordPressやApacheなどは全てインストールされるため、Webサーバ起動後の作業ステップも減らすことができます。
2. WordPressの初期環境構築までの専門スキルが必要ない
上記の特徴を裏返せば、開発者のAWSスキル (AWS専門のエンジニア) が不足している場合でも構築が進められます。
Lightsailを利用すれば、サーバ構築のハードルが下がると言えるでしょう。
3. コストメリットが高い
Lightsailでは、Linuxインスタンスの「4GBメモリ、2コアプロセッサ、80GB SSDディスク、4TBデータ転送」と書かれているタイプが、20USD/月で利用できます。
(アウトバウンドデータ転送の超過分は追加課金)
上記と同じ条件を通常のEC2インスタンスで満たそうとすると、インスタンスタイプにt4g.medium、EBSはgp3の80GB (IOPSとスループットは無料範囲) を選んだ場合、約40USD/月となります。
コストが最優先されるのであれば、Lightsailを真っ先に選んで良いと言えるでしょう。
4. 性能の選択肢が広い
Lightsail=簡易Webサーバのイメージが強いようですが、性能は8vCPU & メモリ32GBの組み合わせまで選ぶことができます。
これだけの性能があれば、Apacheなどのチューニング次第ではありますが、経験上、月間100万PV (30万〜40万UU) であれば困ることはありません。
5. EC2への環境移行も可能
後述のようにIPアドレスを維持することはできませんが、SnapshotをEC2にエクスポートする機能により、後からEC2に移行することが可能です。
Amazon Lightsail を選ぶことによって手放すもの
Lightsailには、このようにメリットが多数ありますが、一方でLightsailを選ぶことによって放棄するメリットもあります。
何を優先するかが、選ぶポイントとなります。
特に大きな選択肢は、初期構築の簡便さを求めるか、リリース後の柔軟な拡張を求めるかです。
1. 環境を維持したままスケールアップ
EC2では、まずインスタンスを停止し、インスタンスタイプを変更し、起動すればスケールアップできます。
しかし、Lightsailではこのような手順でスケールアップできず、一度作成したインスタンスの変更はできません。
どうしても変更したい場合、一度インスタンスのSnapshotを作成し、Snapshotから新たにインスタンスを作り、パブリックIPアドレスを旧→新でアタッチし直す必要があります。
2. Auto Scaling
Lightsailによって作成したインスタンスは、EC2のようにAuto Scalingできません。
3. IAMロール
IAMロールをアタッチすることができないため、AWS CLIや、AWSのサービスアクションを必要とするエージェントを実行したい場合はアクセスキーの発行が必要となります。
但し、アクセスキーを発行してインスタンス内部に格納することはバッドプラクティスなので、EC2ならば回避している実装を敢えて行う必要があります。
4. EC2移行時の同一IPアドレス維持
SnapshotをEC2にエクスポートする場合に、Lightsailで使用していたIPアドレスを維持できませんので、必ずIPアドレスが変更となります。
Lightsail (Instance) で設定できる項目一覧
運用
-
コンソールからSSH接続が可能
-
パブリックIPが自動割当
-
停止・起動・再起動が直感的に可能
監視
-
CPU利用率の監視が可能
-
アラートをEメールで運用者に通知可能
ネットワーキング
-
Security Groupと同様にインバウンドのアクセス制限が可能
- アウトバウンドのアクセス制限は不可
- アウトバウンドのアクセス制限は不可
-
IPv6で接続可能
-
ロードバランサーを利用した負荷分散が可能
-
CDNを利用可能
バックアップ
- 手動スナップショット
- 自動スナップショット (取得時間をHH:mmで指定)
ディスク
- 初期構築時に指定した容量や性能値は、構築後に変更不可
- 追加のディスクをアタッチ可能
ハードウェア (CPU/メモリ)
- 初期構築時に指定した容量や性能値は、構築後に変更不可
タグ管理
- インスタンスにタグの付与が可能
その他
- CloudFormationでリソースの構築と管理が可能
- 但しパラメータの名称と値の定義は、EC2と異なる
- 参考: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lightsail-instance.html
まとめ (所感)
記事執筆時点でLightsailのリリースから約5年が経ちますが、企業が導入するケースはお世辞にも多いとは言えず、主に小規模または検証用途のサービスとして認知されてきた側面が大きいものです。
そんなLightsailですが、近年「内製化」というキーワードがクローズアップされたあたりから、Webサーバ構築の選択肢として急に再注目されるようになってきたと感じます。
再注目の主な要因ですが、自社でAWSエンジニアが育ちきっていない状況でも開発着手のハードルが低く、特にインフラの開発を省力化でき、さらにランニングコストも小さく実現できることが挙げられると考えます。
ノーコード・ローコードと同じとは言えないものの、似たような背景があるのではないかと考えます。
少なくとも、この記事で上げた「手放すもの」を取り急ぎ諦めてでも、コーポレートサイトや自社サービス紹介サイトを最速でリリースすることに尖れば、AWSの数あるサービスの中では最も使えます。
また、従来はEC2を最小構成 (スペック) で構築することが最初のスモールスタートと言われてきましたが、Lightsailはその更に前段に位置づけることができ、ビジネス全体の究極のスモールスタートを支えるサービスとも言えます。
リリース後にビジネスの発展やエンジニアのスキル向上に合わせてEC2に移行し、本格運用に移る選択肢を取れることも、大きなメリットと言えるでしょう。