サービスの公開方法

サービスを公開する方法はたくさんあります。 そのサービスの段階 (コスト、アクセス数) により柔軟に変えていく必要があります。 この記事では、各種デプロイ方法についてまとめています。

1つの記事にまとめると、メンテナンスが大変になるので役割毎に分けて記事にしています。

APIのデプロイ

API、つまりサーバーのデプロイ方法は大きく分けて以下のようになります。 それぞれ独立しているため、いずれかの方法で実施すれば、APIサーバーとして使うことができます。

  • EC2にデプロイする方法
    もっともオーソドックスな方法です。 脆弱性対応やサーバー監視が必要になりますが、Railsなどのフルスタックアプリをそのまま使えるため、PoCとしても大変やりやすいデプロイ方法です。 DBとしてRDSを使う以外に、EC2内でデータを保存しておくこともできます。
  • Lambda (サーバレス) で運用する方法
    脆弱性対応やサーバー監視が不要になり、金銭的にもメリットのある方法です。 EC2にデプロイしたアプリの機能を一部Lambdaにしたり、そもそも大したことをしないのであれば、Lambdaで作るということもできます。DBをDynamoDBやRDSにすると値段が上がり、EC2よりも高くなるケースがあります。 また、Lambdaを使う場合は15分問題 (15分以内に処理を終えなければならない制約) があり、場合によっては運用が難しくなります。 ちなみに、RubyフレームワークのJetsを使うことで、RailsのActiveRecordを使うことができます。
  • ECSにデプロイする方法
    サービスが大きくなると、こちらに乗り換えると有益です。 コンテナで動くため、EC2にデプロイしたコードをほぼそのまま移行することができます。 脆弱性対応もベースイメージを上げるだけで対応でき、タスクの数を自動で維持してくれるため、サーバーが落ちて使えなくなったということもなくなります。
  • AWS外のサービスを利用して安く運用する方法
    VPSや海外プロバイダを利用して、安く運用することもできます。 決裁がやりづらくなったり、サーバー管理・監視も面倒になります。 メリットは金銭的なものだけです。

フロントのデプロイ

フロントのデプロイについては以下の方法についてまとめていきます。

  • Amazon CloudFrontで公開する方法
    S3から直接公開することもできますが、S3の前にCloudFrontを噛ませると有益なことが多いです。 例えば、HTTPSでアプリを公開したり、特定のパスでは処理を変えたりできます。 本記事では 通常のアクセスではS3のファイルを返し、/apiで来たアクセスはサーバー側で処理するというやり方をしています。 また、GoogleかEdgeか、日本か米国かでパスを書き換えて、表示内容を別にするといった処理も間にLambda@Edgeを挟むことで対応できます。
  • AWS外のサービスを利用して公開する方法
    サーバーの場合、AWS以外のサービスを使う旨味があまりませんが、フロントの場合は事情が異なります。フロントの処理は速い方が良いので、世界各地にエッジサーバーを置いているサービスを使ったり、ISRといった最新技術を使いたい場合もあるかもしれません。その場合は、AWSが対応してないので、Cloudflareを使ったり、Vercel、Netlifyを使うケースがあるかもしれません。

コメント