COLUMN

AWSの運用設計の鍵

オンプレミスと比較してクラウドにおけるシステム運用は共通点が多い一方、当然のことながら相違点もあり、その違いを理解することが効果的な運用を実現する鍵となります。この記事ではクラウドにおけるシステム運用のポイントについて解説すると共に、クラウドの利点を最大限に引き出すことができるサーバーレスアプリケーションをAmazon Web Servicesで構築する方法について紹介します。

オンプレミスとの違い

オンプレミスとクラウドの違いの一つは、オンプレミスではシステムに対する責任の全てを原則として自社が負うのに対し、クラウドではシステムの維持責任の一部をクラウド事業者へ委譲する点です。仮にオンプレミスからクラウドへ移行したとすると、オンプレミスでの運用に要していた負荷が軽減されると同時にインフラストラクチャなどのシステムの一部に対する権限を失うことにもなります。権限を失うことが許されうるかどうかは要件次第であり、このようなトレードオフが発生するトピックについて次のセクションから詳しく説明します。

クラウドシステムの運用設計

クラウドネイティブ設計

「クラウドファースト」や「クラウド・バイ・デフォルト」などクラウドという単語が使われた言葉は多いですが、「クラウドネイティブ」や「サーバーレス」という言葉を耳にしたことはあるでしょうか？DockerやKubernetesなどのコンテナ技術の推進を図る団体であるクラウド・ネイティブ・コンピューティング・ファウンデーション（Cloud Native Computing Foundation: CNCF）は、クラウドネイティブを「パブリッククラウド、プライベートクラウドおよびハイブリッドクラウドのように現代的で変化のスピードが速い環境において拡大や縮小ができるアプリケーションを開発・運用する組織に力を与えるもの」と説明しています。一方、サーバーレスアプリケーションの開発ツールとしてポピュラーなServerless Frameworkのドキュメントでは、サーバーレスを「ユーザーに価値をもたらすことに努力を集中し、それ以外のことに一切の時間を使わないこと」と説明しており、クラウドネイティブよりも抽象的な概念となっています。これらの言葉はクラウドにおけるシステム運用においてキーワードとなります。

Undifferentiated Heavy Lifting

前段で、サーバーレスを「ユーザーに価値をもたらすことに努力を集中し、それ以外のことに一切の時間を使わないこと」と説明しましたが、サーバーレスと関連して"undifferentiated heavy lifting"という言葉があります。"Undifferentiated heavy lifting"は日本語に翻訳すると「差別化につながらない重労働」という意味になり、「取り除く」を意味する英単語である"eliminate"を伴ってクラウドコンピューティングの文脈ではしばしば登場します。差別化につながらない重労働を取り除き、ユーザーに価値をもたらすことに集中するという点ではサーバーレスと目的を同じにする概念であるといえます。ユーザーに価値をもたらすことに集中する大切さはオンプレミスにおいても変わりはありませんが、クラウドではこのような重労働を取り除くための仕組みが多くのサービスに組み込まれています。

マネージドサービス

ユーザーに価値をもたらすことに集中するにあたってキーワードとなるのが「マネージドサービス」です。
マネージドサービスとは、クラウド事業者がインフラストラクチャの管理などに一定の責任を持つサービスであり、運用の一部をクラウド事業者に委譲できる分だけクラウド利用者（クラウドを利用したシステムの運用管理者、以下同じ。）はユーザーに価値を提供することに集中することができます。クラウド事業者が責任を持つ範囲はサービスの形態によって異なり、範囲を決める際に重要になる事項の一つが「責任共有モデル」という考え方です。

責任共有モデル

責任共有モデルとは、クラウドの事業者と利用者の間で運用に対する責任を分担する考え方であり、安定的に運用するためのクラウドにおける情報セキュリティマネジメントの基盤となります。原則として、クラウド事業者は「クラウドの情報セキュリティ」に対する責任を負う一方、クラウド利用者は「クラウド内の情報セキュリティ」に責任を負います。
具体的な責任範囲は利用するクラウドの形態によって異なり、例えば、仮想マシンなどのリソースを提供するIaaS(infrastructure as a service)であれば、クラウド事業者はハードウェアや仮想化ソフトウェアの運用に対して責任を負い、クラウド利用者はオペレーティングシステム、ミドルウェア、アプリケーションの運用やデータの管理に対して責任を負います。また、PaaS(platform as a service)やSaaS(software as a service)であれば、クラウド事業者が責任を負う範囲はさらに広くなります。要件を満たす範囲で、よりマネージドサービスを選択することで、運用に要する負荷を軽減することができます。

自動化

要件によってはマネージドサービスを選択することが難しく、インフラストラクチャの管理などの「差別化につながらない重労働」を避けられない場面もあります。そのような場合でもクラウドサービスとして提供される監視や通知の機能を適切に組み合わせ、自動化の仕組みを構築することによって運用の負荷を軽減することができます。マネージドサービスの積極的な利用や自動化により、可能な限り運用の手間を省くことが、クラウド運用における要諦といえます。

サーバーレス設計(開発)の実際

責任を委譲することによって運用の負荷を軽減できるのは良いことですが、それによって生じる制限が開発において足かせとなることもあります。例えば、Amazon Web ServicesのLambdaとAPI Gatewayによるサーバーレスアプリケーションではデプロイパッケージサイズの上限がzip圧縮済みの状態で50MBであることをはじめとして様々な制限があり、要件によってはアプリケーションの開発が困難になる場合もあります。しかしながら、これらの制限が許容範囲内に収まるのであれば最小限の費用と労力で利用することができるので、例えばWebアプリケーションのモックアップを関係者と共有したい場面などで活用することができます。

サーバーレスアプリケーションの開発

前述の通り、システムでクラウドを利用する場合には運用の責任の一部をクラウド事業者へ委譲するため、運用に要する一部の作業をクラウド利用者が行う必要がありません。この利点を体感するために、例として、関係者と共有するためのWebアプリケーションモックアップを構築を、基礎的なサーバーレスアプリケーションとしてAmazon Web Services上で構築する手順を紹介します。

開発用Amazon S3バケットの作成

後の手順でデプロイパッケージを生成する際にS3バケットが必要になるため、CloudFormationを使用してあらかじめ作成します。なお、テンプレート(template-code.yaml)とコマンドの内容はそれぞれ下記の通りです。

[template-code.yaml]

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  Bucket:
    Type: AWS::S3::Bucket

[コマンド]

aws cloudformation deploy --template template-code.yaml --stack-name serverless-code
	
aws cloudformation describe-stack-resource stack-name serverless-code --logical-resource-id Bucket --query StackResourceDetail.PhysicalResourceId

最後に実行するコマンドの出力（例：serverless-code-bucket-tlt3uc7j323）は後の手順で使用するので、テキストエディタにコピーするなどして内容を控えます。

アプリケーションのコーディング

Node.jsのWebアプリケーションフレームワークとしてポピュラーなExpress.jsを使用してWebアプリケーションを作成します。なお、ソースコード(main.js)の内容は下記の通りです。

[main.js]

const express = require('express')
const awsServerlessExpress = require('aws-serverless-express')
const app = express()

app.get('/', (req, res) => {
  res.send('Hello Serverless')
})

const server = awsServerlessExpress.createServer(app)

exports.handler = (event, context) => {
  awsServerlessExpress.proxy(server, event, context)
}

CloudFormationによるデプロイ

AWS Serverless Application Model（SAM）を使用してアプリケーションをデプロイします。なお、テンプレート(template.yaml)とコマンドの内容はそれぞれ下記の通りです。

[template.yaml]

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  Function:
    Type: AWS::Serverless::Function
    Properties:
      Handler: main.handler
      Runtime: nodejs10.x
      MemorySize: 1024
      Timeout: 10
      Events:
        Get:
          Type: Api
          Properties:
            Path: /
            Method: get
Outputs:
  Endpoint:
    Value: !Sub https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/

[コマンド]

aws cloudformation package --template-file template.yaml --s3-bucket serverless-code-bucket-tlt3uc7j323 --output-template-file packaged.yaml
aws cloudformation deploy --template packaged.yaml --stack-name serverless-app --capabilities CAPABILITY_IAM
aws cloudformation describe-stacks --stack-name serverless-app --query Stacks[0].Outputs[0].OutputValue

最後に実行するコマンドの出力（例：https://bijnrhxuhd.execute-api.ap-northeast-1.amazonaws.com/Prod/）はアプリケーションのエンドポイントであり、Webブラウザなどを使用してエンドポイントのURLにアクセスして動作を確認することができます。

おわりに

マネージドサービスの活用によって運用の負荷を軽減できることはクラウドの大きな利点の一つですが、自社システムにおけるコア機能となるような部分についてはあえて「重労働」を引き受ける判断が求められる場合もあります。「これが絶対に正しい」というような基準はないため、特に検討や設計が細部に進んだ段階で判断に迷うことがあります。クラウド選定から運用設計までのあらゆる段階において、クラウド導入(移行)メリットである「アジリティ」、「セキュリティ」、「TCO最適化」が得られるのかという観点で判断しつつ、自社にとって最適な運用のスタイルを模索することが重要となります。