サーバーレスとは

こんにちは、中山( @k1nakayama ) です。

弊社では、以前からAWSクラウドを活用したサーバーレスアーキテクチャでの構築・運用を、お客様へご提案しています。今回はこの「サーバーレス」とはどのようなものかについて、ご紹介したいと思います。

  • サーバーレスとは何か知りたい方
  • サーバー障害や普段の管理業務に追われている方
  • アプリケーション開発に集中して取り組みたい方

従来のサーバー運用

みなさんはオンプレミスでのサーバー運用をされた経験はありますか?オンプレミスと言っても、社内でのサーバー運用はもちろんのこと、データセンターでのハウジングや、レンタルサーバーを利用したホスティングサービスの利用などをされていた方などもいるかと思います。最近では、クラウドの利用を前提にプロジェクトを立ち上げるケースも多く、若手のエンジニアの方などでは、そもそもこのようなオンプレミスでの運用をされことが無い方も多くなってきました。

オンプレミスでサーバー運用をする場合に、新規にサーバーを立ち上げる際、少なくとも下記のような作業が必要となります。

  1. サーバーのスペック検討(CPU、メモリ、ストレージ容量などなど)
  2. サーバーの発注(ハウジングや社内サーバーの場合、数週間〜1ヶ月前後かかることも)
  3. サーバーのラック設置(電源、ネットワークの配線を含む。ホスティングの場合はホスティング事業者がやってくれます)
  4. OSインストール(ホスティングの場合はホスティング事業者がやってくれます)
  5. 各種ミドルウェアのインストール(ApacheやNginxなどのWebサーバ、PHPやRuby等のランタイム、MySQLやPostgreSQL等のDBサーバ、などなど)
  6. 監視・運用のための設定(監視エージェント等のインストール、ログローテート等の設定など)

上記の作業を終わらせるだけでも、レンタルサーバーのような比較的早くサーバー運用をはじめられる方法であっても、1週間前後は掛かってしまうかと思います。もちろん、ハウジングや自社サーバーの場合、サーバー手配だけでも時間がかかる為、場合によっては2ヶ月近くかかる可能性もあります。

また、サーバーは立ち上げた後からが本番です。様々な運用中のインシデントに対応していかなければなりません。

例えば下記のようなインシデント対応はよくあるものではないでしょうか?

  • アクセス急増によるサーバー接続不可
    • 急に追加のサーバーを立ち上げられないため、急増の原因を調査し、攻撃等であればリクエスト元を制限するなどの対処を行う。攻撃等ではなく、通常の運用で急増した場合は、アクセスを落ち着かせるための対処を検討したり、メンテナンス表示に切り替えるなどの対応をして対応策を検討
    • このようなインシデントが発生しないようにするために、想定される年間のスパイクリクエスト時に必要なスペックやサーバー台数より多くのリソースを用意しておく
  • 日々の運用で発生したログファイルやトランザクションデータ等により、ストレージ容量が枯渇し、最悪の場合Read Only状態となる
    • 不要なファイルの削除作業
    • より大きな容量のストレージへファイルの移行を行い、ストレージの交換または追加を行う
  • NIC(LANケーブルを接続する装置)の故障や上位ネットワーク機器や回線のトラブルによる接続不良
    • NIC故障の場合はNICを交換する作業を即座に実施
    • 上位ネットワークの問題については、原則として復旧を待つことしか出来ないケースが多い(バックアップ回線が用意されている場合は、回線の切り替えを実施)

この他にも、セキュリティインシデントなどを防止するためにも、日々OSやミドルウェアのアップデートを実施することや、データのバックアップ作業などをルーチンワークとして行っているケースが多いかと思います。

オンプレミスで運用するためには、ここに挙げただけでも様々な場面で、高度な知識を持つネットワークエンジニアなどの対応が必要となります。

仮想サーバー(Amazon EC2)で運用

初めてお会いするお客様に、「サーバーレスについてご存知ですか?」とお聞きすると、「自分で管理していたサーバーをクラウドに移してサーバーなくすってことですか?」と言われることがとても多いです。

ここで言われている「自分で管理していたサーバー」はオンプレミスのこと、「クラウドに移した(サーバー)」はクラウドサービス上で運用する仮想サーバー(IaaS)を指していることがほとんどです。AWSの場合、仮想サーバーサービスとして提供されているものが、「Amazon EC2(Amazon Elastic Computer Cloud)」になります。恐らくEC2は利用されたことがある方や、名前は知っているという方は多いのではないでしょうか?

実は「サーバーレス」はこのような仮想サーバーを利用した運用形態を指すのではありません。

このEC2をはじめとした仮想サーバー運用を行っていく上でも、オンプレミス運用に比べ大幅な作業負荷の軽減にはなるものの、ミドルウェアのインストール作業や、サーバー監視・運用のための設定などを行う必要はあります。

また、EC2を使った場合でも運用中のインシデント対応については、概ねオンプレミス運用と同じ対応が必要です。

EC2の場合はオートスケーリングがあるし、ストレージも後から拡張できるから、全然オンプレミスと違うよ!という声が聞こえてきそうなので、この点についても補足をしておきます。

EC2は確かにオートスケーリングと組み合わせることにより、CPU使用率等の上昇に伴ってインスタンスをスケールアウトさせることが可能です。このため、サーバーへのトラフィックが増えてきた場合などにインスタンスを増やして受け皿を広げ、より多くのリクエストをさばくことが出来ます。

しかし、EC2は起動し終えるまでに数分程度掛かります。オートスケーリングによるスケーリングをトリガーするアラームのモニタリング間隔も関連し、実際のリクエストが急増するワークロードにおいては、これらのオートスケーリングを発動させる設定について、適切な設定を行うこと自体がとても難しく、日々の調整が必要となる部分になります。

また、ストレージ容量についても常に使用量について把握をしておき、タイミングをみてストレージ容量の拡張作業を行うようにする必要があり、いずれにしてもサーバー管理者が適切に管理を行えている必要があります。

ネットワークについても同様で、障害の発生しているアベイラビリティゾーン(AZ)にサーバーを起動してしまうと、ユーザーが接続しようとしたタイミングで接続不良が発生する可能性があります。そのため、障害が発生しているAZにトラフィックを送らないように設定していくことなども時には必要だったりもします。

更に、オンプレミスと同様に仮想サーバー上のミドルウェアの設定やバージョン管理などは、全て利用者側の責任で運用することとなります。そのため、ミドルウェアのアップデートなどを怠っていると、攻撃者からそのセキュリティホールを突いた攻撃を受け、大事な情報を漏洩してしまったり、サービスへの大きな影響を与える可能性があります。

サーバーレスアーキテクチャ

これまでオンプレミス等でサーバー管理をしっかりされてきた方からすると、上記で述べてきたことは当たり前のことであり、インターネット上でサービスを提供する上でのサービス提供者が負うべき義務だ、というように感じている方もいらっしゃるかと思います。従来までは私もその様に感じていました。

しかし、2014年にAWS Lambdaというサービスが登場し、これまでの常識が一変したのです。

これは運用形態ごとのAWSが定める責任共有モデルを表したものです。

これまでに説明してきたとおり、オンプレミスの場合、ラック周りの管理からOS、ミドルウェア等の管理、更には運用時の可用性やスケーラビリティ等の管理まで全てにおいて自ら管理をする必要があります。

EC2を使用した仮想サーバーで運用をする場合、ラックの管理やOSの導入まではAWS側に管理を委ねることが出来ますが、OS上のパッチ管理をはじめ、ミドルウェアの管理、運用時の可用性やスケーラビリティの管理などは引き続き行う必要があり、概ねホスティングサービスと変わらない管理が必要となります。

これらに対し、AWS Lambdaをはじめとするサービスでは、ミドルウェアの管理やバックアップ、更には可用性やスケーラビリティの管理に至る運用面の必要な管理を全てAWSに委ねることが出来ます。

つまり、ミドルウェアは常に最新の状態に保たれ、アップロードしたデータは世代管理することが簡単にでき、複数のデータセンターにまたがってデータが保管されることによりデータの破損や消失といった問題が一部で発生した場合でも、すぐに復旧することが可能であり、サービスが提供されるホストコンピューターが障害によりダウンした場合でも、利用者側に影響なく継続して利用が出来るよう自動的に問題のあるホストへのルーティングは避け、常に高可用な状態で運用できる体制を維持してくれます。

このように、サーバー運用についてこれまで十分に意識して運用してきた事柄を、その大半について意識する必要なく運用を行うことが出来るサービスや、SaaSのように利用者側がサーバーについての運用や責任を持たないサービスだけを組み合わせて構築する設計を「サーバーレスアーキテクチャ」と呼ばれています。

そしてこのような、サーバーレスアーキテクチャで構成されて運用されるアプリケーションを、「サーバーレスアプリケーション」と呼んでいます。

自分たちがこれまで意識してこなければいけなかった「サーバー」について、意識すること無く運用できることで、あたかもサーバーが無いかのごとく運用を行えることから「サーバーレス」と言われるようになったようです。

AWSのサーバーレスサービス

上記について「サーバー管理・運用について意識する必要なく運用を行うことが出来るサービスだけを組み合わせて構築する設計」を「サーバーレスアーキテクチャ」と伝えましたが、このようなサービス(サーバーレスサービス)には、下記のようなサービスが挙げられます。

AWS Lambda

FaaS (Function as a Service)として代表的なサービスであり、AWSのサーバーレスサービスの代表格的なサービスです。このAWS Lambdaは、コードの実行環境を提供するコンピューティングサービスであり、ユーザーはコードを書いてAWS Lambdaに乗せるだけで、ランタイムなどのインストールなどを行わずに、即座に実行を行うことが出来ます。また、課金も実行した時間のミリ秒単位での課金となるため、まさに使った分だけの課金となります。

Amazon API Gateway

REST APIを公開するための様々な機能を提供するサービスです。API GatewayとLambdaを組み合わせることで、SPA(Single Page Application)で配信されているWebサイトや、モバイルアプリなどにAPIとして様々な機能を提供することが出来ます。API GatewayはLambda以外にも各種AWSサービスと直接つなぎこむことが可能です。また、外部で提供されているHTTPエンドポイントにつなぎこむことも可能です。

AWS AppSync

GraphQL APIを公開するための様々な機能を提供するサービスです。LambdaやDynamoDB、OpenSearch Service、HTTPエンドポイントなどとつなぎ込んでリクエストを処理することが可能です。

Amazon DynamoDB

Key-Value型のNoSQLデータベースサービスであり、1桁ミリ秒でデータにアクセスすることが可能で、あらゆる規模に対応することができるサービスです。様々なワークロードで使用可能なため、サーバーレスアーキテクチャではLambdaと組み合わせて使われることの多いサービスの1つです。

Amazon S3(Amazon Simple Storage Service)

Amazon S3は容量無制限で使用可能なオブジェクトストレージサービスです。このストレージの特徴の1つとして耐久性が99.999999999%というとても高いものとなっており、AWSが提供する様々なサービスを含め、多くのアプリケーションでデータストアとして使用されています。

Amazon EventBridge

Amazon EventBridgeはイベントバスを提供するサービスです。様々なイベントをEventBridgeに送ることで、それらのイベントを受け取りたい別のサービスに配信することが出来ます。受信対象のイベントは、高度なフィルタリング機能を用いて条件に該当するイベントのみ受信することが可能です。

Amazon SQS(Amazon Simple Queue Service)

Amazon SQSはメッセージキューイングサービスです。キューに格納されたメッセージを順序に関係なく取り出し高速に処理を行う標準キューと、格納された順序に従ってメッセージが処理されるFIFOキューを定義することが可能です。また、SQSとLambdaを組み合わせることで、SQSにメッセージが格納されたタイミングで、自動的にLambda関数を呼び出すことも可能です。

Amazon SNS(Amazon Simple Notification Service)

Amazon SNSは、メッセージをアプリケーション対アプリケーションやアプリケーション対個人のメッセージングを管理するサービスです。基本的に特定のトピックを受信したいアプリケーションや個人がサブスクライブしておくことで、トピックにメッセージが送信されると様々な方法でメッセージを受け取ることが可能です。メッセージの配信先として、SQSキュー、Lambda関数、HTTPSエンドポイント、Kinesis Data Firehoseなどを指定でき、送信先が個人の場合、メールアドレス、モバイルプッシュ、SMSなどを指定することが可能です。

Amazon CloudFront

Amazon CloudFrontは、グローバルにデータ、動画、アプリケーションおよびAPI等を低レイテンシーに配信するためのコンテンツ配信ネットワーク(CDN)です。WebアプリケーションでのWebコンテンツや、画像や動画等のデジタルコンテンツを配信するために使われることが多いサービスです。また、エッジでLambda関数を実行しリクエストに応じた動的な処理を実行することも可能です。

Amazon Cognito

Amazon Cognitoは、ユーザーのサインアップ、サインインとそれぞれのユーザーに対するアクセスコントロールを提供する認証、認可のサービスです。Webアプリケーションやモバイルアプリケーションにおけるユーザー管理を簡単に実装することが可能となるサービスです。

AWS Step Functions

AWS Step Functionsは、ワークフローをビジュアル的に定義することが出来るAWSサービスのオーケストレーションサービスです。Step Functionsを使うことで、並列処理、条件分岐、再試行などの様々なフローをLambdaをはじめ様々なAWSサービスと統合して実行することが可能です。従来のバッチ処理などについて、サーバーレスアーキテクチャで構成する際には、Step FunctionsとLambda等を組み合わせて処理することができます。

Amazon SES(Amazon Simple Email Service)

Amazon SESは、メールの送受信を行うためのサービスです。メール送信はSDKや直接APIを叩いて行うことの他、SMTPを通して送ることも可能です。不達となった送信先に何度も送信し続けないようにする管理なども自動化されており、大量のメールを素早く配信するために必要な環境が提供されます。

Amazon Athena

Amazon Athenaは、S3上に配置されたデータを対象に、標準的なSQLを使用してデータの分析が行なえます。例えばアクセスログなどのログファイルを、S3に保存していき、それらを条件に従って抽出することが出来ます。

AWS Glue

AWS Glueは様々なデータソースからデータの抽出、変換、読み込みといった、いわゆるETL処理を行うためのサービスです。このGlueを使用することで、異なるデータソース間でデータ抽出を行い、必要な形に変換した後、新たなデータベース等にデータを読み込ませることが可能となります。

Amazon Timestream

Amazon Timestreamは、時系列ベースのデータベースサービスです。IoTやDevOps(運用管理)において、多くの時間を軸としたデータが扱われますが、これらの時間軸をキーに保存されたデータを、様々な時系列分析関数を使用して分析することが可能です。

Amazon QLDB(Amazon Quantum Ledger Database)

Amazon QLDBは、台帳データベースサービスです。入力されたデータはイミュータブルで透過的に管理され、全ての変更履歴は順に追跡し管理されます。また、それらのログは全て暗号的に検証可能なトランザクションログとなっています。

Amazon QuickSight

Amazon QuickSightは、BIツールです。様々なデータソースからデータを分析し、素早くダッシュボードにデータをビジュアライズされた形で表示することが出来ます。また、組み込みのML機能により、自然言語で分析条件を入力されたものに対して結果を表示することも可能です。

まとめ

サーバーレスとはどのようなものか、について解説してきました。

サーバーレスアーキテクチャで構成することにより、アプリケーションを運用する際に、サーバーについて意識をすることなく運用することが出来ます。これにより、これまでサーバー運用やインシデント対応に費やしていた時間や人員を、アプリケーションの開発に集中することがしやすくなります。

サーバーレス開発についてのご相談

クラウドパートナーでは、このようなサーバーレスアーキテクチャを用いて、お客様の様々な課題について解決していくご提案を行っております。

また、サーバーレスアプリケーションの開発を弊社にて行い、お客様はアプリケーションの運用を行っていく形を取ることも可能ですが、昨今ではアプリケーションの継続的な改善や、新機能の追加等を行っていくために、お客様社内でのサーバーレス開発の内製化を支援するご提案も行っております。

現在のお客様社内において課題がありましたら、ぜひ一度ご相談ください。

無料相談実施中
AWSを使用したサーバーレスアプリケーションの構築
サーバーレス開発内製化、AWSへの移行等
様々な課題について無料でご相談お受けいたします。
サーバーレスとは
最新情報をチェックしよう!