AWSに関するありがちミスとその対策～EC2、S3、RDS、Lambda、CloudFrontの場合

1. なぜ、AWSを選ぶのか？
2. Amazon EC2～インスタンス起動後はプライベートIPを設定できないので注意
3. Amazon S3～S3はディスクではない。マウント非推奨の理由
4. RDS～自動スナップショットの保持期間を0にし「スナップショットをとらない」状態に
5. AWS Lambda～よくあるトラブルはタイムアウトエラー
6. Amazon CloudFront～意図せぬキャッシュでの情報漏洩に注意
7. 総括

Webエンジニアなら誰もがその名を知るクラウドサービス、アマゾン ウェブ サービス（以下、AWS）。法人・個人問わず利用ユーザが増え続けているため、もはや若手インフラエンジニアにとっては「必修科目」になりつつあるでしょう。

一方で、サービス範囲が非常に広いことから、「なにを使えばいいのか？ なにを勉強すればいいのか？」という悩みもあるかもしれません。今回はそんな悩みを解決するヒントを探るべく、「cloudpack（クラウドパック）」と呼ばれるAWS導入・運用支援サービスを提供し、800社を超える企業へのAWS導入、その後の運用サポートも手掛ける、アイレット株式会社のエンジニア3名に「まずは押さえておきたいAWSサービス」を聞きました。

本稿ではAWSの中でも多くのユーザに支持されている5つのサービス、Amazon EC2（以下、EC2）、Amazon S3（以下、S3）、Amazon RDS（以下、RDS)、AWS Lambda（以下、Lambda）、Amazon CloudFront（以下、CloudFront）それぞれの勘所やオススメの設定を余すところなく紹介してもらいます。サービスを使い始めたユーザの多くが「ハマりやすいポイント」にも触れているので、ぜひ参考にしてみてください。

Amazonクラウドでビジネスを加速｜AWS専業のcloudpack（クラウドパック）

クラウドの活用とシステム開発ならアイレット株式会社

なぜ、AWSを選ぶのか？

10年以上のクラウドインフラ運用ノウハウと、大小問わず多くの企業に導入されている実績

――今でこそ多くのユーザを抱えるAWSですが、運用開始から10年を超えるんですね。

栄野川　2006年3月にリリースされたS3を皮切りに、同年後半にはEC2が公開されたものの、当時はユーザが具体的な導入イメージを描けず、盛り上がりはいまひとつだったようです。

弊社がAWSを知ったのは、海外拠点のWebサイトを立ち上げたいと考えられていたお客様から「現地のホスティングサービスで、何を選べばいいか」というご相談を受けたのがきっかけだったと聞いています。2009年から導入支援サービスの「cloudpack（クラウドパック）」を始めて以来、少しずつ利用されるお客様が増え、現在は国内外合わせて840社を超えるAWS導入のサポートをしています。

AWSの認知度が一気に高まったのは2014年のCIA事件と言われており、多くの機密事項を管理するCIA（Central Intelligence Agency：米中央情報局）が、情報インフラをIBM製のオンプレミスシステムからAWSに切り替えました。政府機関、しかも多くの機密事項を抱えているCIAがクラウドサービスに乗り換えたという事実に、IT業界には激震が走ったようです。

日本でクラウドが注目され始めたのは2011年の東日本大震災がきっかけだと言われています。クラウドサービスのメリットのひとつ「Disaster Recovery（災害復旧）に向いている」ことが見直され、国内企業での導入が進みました。

サービスの広がり方から「スタートアップやスモールビジネスに強い」と言われがちなAWSですが、近年はエンタープライズでの導入も進み、cloudpackのクライアント様はスタートアップ、中規模企業、大企業の割合はほぼ等しい状況です。

他社クラウドサービスとの単純比較はナンセンス

――AWS以外のクラウドサービスも、認知度が高まってきています。

栄野川　「他社のクラウドサービスとAWSはどこが違うのか」とはよく聞かれます。しかし他社クラウドとの単純な機能比較は、各社で力を入れている部分が違うためナンセンスだと思います。

AWSの強みは、蓄積されたノウハウの量と機能追加スピードの早さです。後発サービスのMicrosoft Azure（2010年サービス開始）やGoogle Cloud（2014年サービス開始）に比べ、圧倒的な運用ノウハウを持ちます。またAWSは「一度発生させたトラブルは二度と起こさない」という姿勢を重んじており、障害対応も迅速です。

合わせて公開サービスの改善や機能追加にも力を入れており、現在は年間1000超の機能追加がされています。

Amazon EC2

Amazon EC2 (安全かつスケーラブルなクラウド上の仮想サーバーホスティング) | AWS

ユースケース

栄野川　EC2はApache、MySQL、PHP、Ruby on Railsなどを使った動的なサイトを構築するときに使われる仮想サーバをクラウド上で提供するサービスです。AWSで提供されているサービスの中では、チームの規模を問わず最も使われているサービスだといえるでしょう。

EC2が作動しているAWSサービスも多いです。例えばWebアプリケーションのデプロイや構成管理ができるElastic Beanstalk、ビッグデータを処理・分析するAmazon Elastic MapReduce（EMR）でもEC2インスタンス（EC2でのコンピューティング仮想環境）が後ろ側で動いています。

インスタンスメタデータにHTTPリクエストを送ると……

――最も使われているサービスとのことですが、意外と知られていない機能もあると伺っています。

栄野川　インスタンスメタデータ（EC2固有の機能。EC2の中からしかアクセスできないIPアドレス）にHTTPリクエスト169.254.169.254を送ると、さまざまな情報を閲覧できます。

• 自身のインスタンス識別ID
• パブリックIPアドレス
• OS
• IAM Role
• ホストネーム
• 自分がどのネットワークにいるか

インスタンス起動後はプライベートIPを設定できないので注意

――EC2の利用者が陥りがちなミスなどはあるのでしょうか？

栄野川　多いトラブルが起動時の設定ミスです。EC2はインスタンスを一度起動してしまうと、以下のような後から変更できない項目がいくつかあります。

特に気を付けたいのはネットワーク設定。利用者が特に指定をしない場合はAWS側が自動的にDHCPで起動するので、プライベートIPアドレスがランダムで配分されます。また、起動後はVPCの変更ができなくなるため、プライベート、パブリック含めたサブネットを指定した設定には注意が必要です。

また、サービスのスケーリングを考えるときに気を付けたいのが、コンテンツ同期と負荷分散です。

複数のサーバ間でコンテンツの同期を取らずに「アクセスごとに挙動が変わってしまう」というお客様からの問い合わせも少なくありません。サーバのディスク内にある画像データなどをS3に配置しておく、同時デプロイでコンテンツが同期されるようにする、などの仕組みづくりを忘れずに行ってください。

数千台の運用をサポートさせていただいていると、EC2の障害に起因しアクセスができなくなってしまうケースも少なくないなと感じます。サーバが落ちることを前提に考えた設計にした方がいいでしょう。ダウンタイムが許容できないなら、ロードバランサのElastic Load Balancing（ELB）をEC2の前に置いて冗長化した負荷分散をおすすめします。

コラム：タグ機能を活用して、インスタンスを制御

EC2に限りませんが、「タグ」機能を活用するとインスタンス制御が便利になります。

• KeyValue形式
• Name KeyをValueで指定
• Value＝インスタンス名

インスタンスの役割ごとに共通のタグを設定し、APIでデプロイするときに「roleタグがWebの場合のみデプロイされる」という動かし方も可能です。

自動で起動、停止するスクリプト（自作）で「特定のKeyがついているインスタンスだけ平日の営業時間外に起動する」。AWS Lambdaと組み合わせると、複数のインスタンスを動作制御できますし、スクリプトを他のインスタンスにも使い回せるのでおすすめです。

栄野川直斗さん：沖縄国際大学卒業後、2015年4月に新卒でアイレットにジョイン。主に金融関係やECサイトのAWSインフラ構築および運用を担当。好きなAWSサービスはAutoScaling。

Amazon S3

Amazon S3（拡張性と耐久性を兼ね揃えたクラウドストレージ）｜AWS

ユースケース

――S3もEC2と同じ、オンライン仮想サーバですね。

栄野川　S3は静的なストレージサービスとして知られています。EC2やRDSのスナップショットもS3に保存されます。

「AWSをとりあえず触ってみたい」と考える人にとって、S3はハードルが低いと思います。公式ドキュメントにあるチュートリアルにそって動かせば、簡単にWebサイトが公開できます。AWS未経験のエンジニアにも「一度S3やってみれば」というように薦めることが多いです。

S3を使う上で知っておきたいのは、静的Webサイトのホスティング機能です。時折Webサイトの立ち上げを考えているお客様から「S3だけでなく、物理サーバも必要？」という問い合わせがあるのですが、HTML、CSS、JavaScriptや画像も埋め込めるのでS3のみでホスティングが可能です。サーバをレンタルするなどの手間もなく、安価にサイトが運用できるので便利です。

EC2と連携するケースが多い

――S3は他のサービスと連携されることも多いですよね。

栄野川　EC2と連携されるケースが目立ちますね。PHPで動くWordpressなど動的なサイトはEC2、/wp-content配下など静的なコンテンツはS3で運用、さらにCloudFrontとも連携できます。

CloudFrontのBehaviors機能でPath Patternを設定することで、拡張子やパスに応じたキャッシュコントロールができます。

ログ転送ツールFluentdを使い、EC2からのログをS3に保存することも可能です。EC2にエージェントを仕込んで、定期的にシスログやアクセスログをS3バケットに出力するのもよくあるケースです。

EC2以外のさまざまなAWSサービスと組み合わせるケースもあります。Amazon Lambda（Lambda）をデプロイする際に、Serverless Framework（サーバレスフレームワーク）で権限を設定したり、Lambdaにコードを自動デプロイする、といったこともできます。

CloudFrontによるパス振り分け&アクセスログの転送例。

S3はディスクではない。マウント非推奨の理由

――S3で起こりがちなトラブルはあるのでしょうか？

栄野川　S3をNAS（Network Attached Storage）の代替にする、と耳にすることもありますが、S3をディスクとみなして扱うのはお勧めしません。「EC2からS3をマウントしたい」というご要望もいただくのですが、弊社ではS3のマウントを推奨していません。

HTMLファイルやアクセスが多いコンテンツに対してS3をマウントさせると、EC2からAPIを通してS3にアクセスするのでラグが発生します。大量アクセス時に頻繁にマウントが外れてS3にアクセスできなくなり、サービスに影響が出てしまう可能性もあります。

アクセス対策としてはDatadogなどの監視ツールを導入し、マウント外れが起こったら再度マウントする設定にしておくほか、CloudFrontを使った構成にしておきましょう。

RDS

Amazon RDS（クラウドでのリレーショナルデータベースサービス） | AWS

ユースケース

栄野川　RDSはスケーラブルなフルマネージドのDBサービスです。AWSが提供するRDSエンジンAmazon Aurora（Aurora）はもちろん、MySQL、PostgreSQL、MariaDB、MS SQL Server、Oracleに対応しています。

AWSには複数のDBサービスがありますが、代表的なものは以下の3種です。それぞれ違った特徴があるのでご紹介しましょう。

• RDS for MySQL

  • 概要：Amazon RDSによって、MySQLのデプロイをクラウド内で簡単にセットアップ、運用、スケールできる。Amazon RDSを使用すると、コスト効率が良く、サイズ変更が可能なハードウェア容量で、スケーラブルなMySQLサーバーを数分でデプロイ可能
  • 特色：MySQLのエラーログやスロークエリログをCloudWatch Logsへ転送できる。なお、2018年6月現在はMySQLとMariaDBにのみ提供されている機能

• RDS for Aurora

  • 概要：Amazon Auroraは、クラウド向けに構築され、MySQLやPostgreSQLと互換性のあるリレーショナルデータベースで、高性能の商用データベースのパフォーマンスや可用性と、オープンソースデータベースのシンプルさや費用対効果を兼ね備えている。
  • 特色：Auroraは、標準的なMySQLデータベースと比べて最大で5倍、標準的なPostgreSQLデータベースと比べて最大で3倍高速化できる。また、商業用データベースと同等のセキュリティ、可用性、信頼性を10分の1のコストで実現する

• Dynamo DB

  • 概要：Amazon DynamoDBは、どのような規模においても整合性と1桁ミリ秒単位のレイテンシーを必要とするアプリケーションに対応した、高速かつ柔軟な非リレーショナルデータベースサービス
  • 特色：EC2だけではなくLambdaなどのサーバーレスとの相性が良い。用途によって読み込み/書き込みの性能（キャパシティユニット）を柔軟に変更することが可能

自動スナップショットの保持期間を0にすると「スナップショットをとらない」状態にできる

――RDSを使う上で、おさえておきたい設定はありますか？

栄野川　バックアップ保持期間を0に設定すると、「自動バックアップをとらない」状態にすることができます。しかし「やはりバックアップをとりたい」と考えて0から1以上の数に設定し直すと、RDSが再起動してしまいます。

詳しくは公式ドキュメントにも記されています。

バックアップ保持期間

DB インスタンスを作成するとき、バックアップ保持期間を設定できます。

（中略） Aurora 以外の DB エンジンの場合は、バックアップ保持期間を 0 に設定して、自動バックアップを無効にすることもできます。自動バックアップには、手動スナップショットの制限 (リージョンごとに 100) は適用されません。

参照元：バックアップの使用 - Amazon Relational Database Service

RDS要注意ポイント(1)　パラメータグループ「デフォルト」

――RDSを扱う上での注意点を伺いたいです。

栄野川　注意したい点は大きく2つです。

ひとつは起動時の設定です。デフォルトのままインスタンスを起動してしまうと、パラメータ設定が設定されず、RDSの再起動が必要になる場合もあります。

RDS要注意ポイント(2)　RDSを消すと、スナップショットも同時に消える

栄野川　もう1つ、RDSインスタンスの削除は慎重に行ってください。インスタンスの削除と同時に自動でとられた自動バックアップデータも同時に消され、データの復旧ができなくなってしまうのです。「バックアップの状態に戻したい」ときに間違って現在の状態を削除してしまった場合も同様です。

対策はこの3つです。

• スナップショットを手動でコピーする
• RDSを別の名前に書き換えて起動する
• DBのエンドポイントを変える

このトラブルは本当に要注意で、社内のメンバーも間違って削除した経験があるくらいです（笑）。AWSにも問い合わせがあるようで、最近はRDSの削除前にダイアログを出すようになりました。

RDS削除前に出るダイアログ。スナップショットの作成や、削除への同意チェックがユーザに通知される。

他にもある、気を付けたいポイント

――他にも、気を付けたい点があれば教えてください。

栄野川　ありがちな「うっかり」はこの2点でしょうか。

1. RDS自体にはSSHログインができない

   • MySQLクライアントなどでRDSにログインする

2. RDSのデフォルト設定では、自動でマイナーバージョンがアップデートされることがある

   • 基本的にも事前通知があるので、事前対応も可能

AWS Lambda

AWS Lambda (サーバーレスでコードを実行・自動管理) | AWS

ユースケース

――Lambdaは使いこなすと便利な反面、初めて使う人にはややハードルが高いと聞きます。

和田　難しく考えなくても大丈夫です。Lambdaはサーバ上でプログラムが実行できるサービスで、ローカルで書いたプログラムをアップロードするだけでなく、Lambdaの管理画面（コンソール）に直接コードも打ち込めます。

物理サーバを管理せずにプログラムが実行できるので、RDS、S3、DynamoDB、Kinesis¹など各種AWSサービスや外部APIと組み合わせてサーバレスなインフラを構築できます。AmazonのAI音声アシスタント・AlexaのバックエンドもLambdaでの構築を推奨しています。

使える言語はNode.js、Python、Java、C#、Go。「フロントが強いからNode.js」「インフラ系ならPython」というように自身のスキルに合わせて、負担なく選べるのが嬉しいところです。今後はGoを使うユーザも増えていくのではと思います。

和田健一郎さん：國學院大学卒業後、中堅SIベンダーを経て、2016年9月にアイレットにジョイン。アプリエンジニアとして、Lambdaを使ったAPIの設計・開発を担当。好きなAWSのサービスは、AWS Lambda。

マイクロサービスのようなライトな処理に向く

――Lambdaの強みを生かせる設計や、他のAWSサービスとの組み合わせはありますか？

和田　Lambdaの強みを生かせるのはAPI Gateway²との組み合わせです。マイクロサービスのように、ライトな処理を複数用意するときには強いものの、長時間のバッチ処理には向かないこともあるので注意が必要です。処理時間が長いシステムには、EC2など、他のAWSサービスを利用する方が向いているケースがあります。

もしくはLambdaを複数用意し、それぞれを連携していって負荷を分散させるなど、向き不向きを見極めて使うことが重要です。

Lambdaで多いトラブルはタイムアウトエラー

――初心者がLambdaでつまずきやすいポイントを教えてください。

和田　Lambdaでよくあるトラブルがタイムアウトエラーです。LambdaをVPCに入れて動かすと起動時間が通常より遅くなることがあります。

そのため、他のサービスとの組み合わせによってはしばしばタイムアウトエラーを起こしてしまうこともあります。特に一緒に使われることも多いAPI Gatewayは応答待ちが29秒続くと接続を中断しエラーを返してしまうので、Lambdaの起動に時間がかかった場合、タイムアウトしてしまう場合があります。

プログラムの書き方を見直したり、言語のバージョンを適切に選んだりする他、ユーザ（クライアント）側でリトライすることを前提とした作りにした方がいいでしょう。

動作制御に関するお問い合わせもよく受けます。意図せずに1回以上非同期処理が動く可能性を認識し挙動を制御するために、処理済みフラグを立てるなどの対策が必要です。

Lambdaの特性を理解して設計しよう

和田　マイクロサービスアーキテクチャやサーバレスは、オンプレミスとは仕組みが違うので、オンプレ環境の代替として捉えない方がいいでしょう。

例えば処理時間。Lambdaの処理時間は最大5分です。「オンプレではできたのに、なんでLambdaではできないんだ」と考えず、別の物として考えると使いやすくなると思います。

オンプレミスからいきなりLambdaを導入するのではなく、EC2などのAWSの他サービスを経てLambda（サーバレス）と段階を踏んで導入されるお客様もいらっしゃいます。

このようにお話していくと、導入ハードルがやや高いと思われがちですが、Lambdaはオンプレに比べてトライアンドエラーがしやすい環境です。Lambdaのフレームワークやチュートリアルも充実しているので、個人でもぜひ挑戦してほしいです。JavaやGoはクライアント側のビルドが必要なので「とりあえず試したい」という方はNode.jsやPythonでトライしてみてください。

その際、いちから作るのではなく、AWSが用意しているBlueprintと呼ばれる設計書を使ってみると、より容易に設計ができ、理解も深まるかと思います。

Amazon CloudFront

Amazon CloudFront（高速コンテンツ配信ネットワーク - CDN） | AWS

ユースケース

駒澤　Amazon CloudFront（CloudFront）はCDN（Content Delivery Network）サービスです。オリジンサーバから取得したコンテンツを世界各所に存在するエッジサーバに送り、各エッジサーバに物理的に近いユーザへコンテンツを返す、という一連の流れを担います。

当社が関わらせていただいている様々なWebサイトで、CSSなど静的コンテンツはもちろん、動的コンテンツにも適宜キャッシュ設定を行いCloudFrontから配信しています。なお、キャッシュできないコンテンツはキャッシュせずに配信しています。

予測不可能な突発的アクセスがあるサイトには特にCloudFrontの利用を推奨しています。例えばヤフトピ砲やLINE砲、スマートフォンアプリでのプッシュ通知といった、ユーザからのアクセスが集中する局面が想定される場合です。

こうした突発的アクセスに対応するには、オリジンサーバを常に並べておく必要がありインフラコストが高くついてしまいます。しかしCDNを使えば、実際のアクセスに合わせて処理するアクセスの閾値を大幅に上げられるので、コストが節約できるのです。

このようにオリジンサーバの負荷軽減のほか、ネットワーク転送量の節約やDDoS対策にも効果があるといえるでしょう。

初めて使う人におすすめしたい、3つのこと

――CloudFrontを初めて使う方におすすめの構成や、使う上で便利な小ワザはありますか？

駒澤　初めて使う人におすすめしたい構成と機能はこの3つです。

1. S3とCloudFrontの構成
   静的コンテンツはS3のStatic Website Hosting機能を利用して配信可能です。さらにCloudFrontを導入することで、大量のリクエストを処理することが可能になります。加えて、CloudFrontにてSSL証明書を使用すると、WEBサイトをHTTPS化することができます
2. アクセスログはS3に保存しよう
   アクセスログはデフォルトの設定だと出力されません。意図しないキャッシュの挙動が発生した場合に調査するためにアクセスログが必要となります。アクセスログをS3に保存する設定を有効にしましょう。S3のライフサイクル設定を利用すれば、一定期間が経過したログを自動的に消去されるので、ストレージ容量の節約につながります
3. 「キャッシュ統計レポート」を活用
   キャッシュ統計レポートではリクエスト数やデータ転送の傾向、エラー発生率（発生数）のほか、キャッシュヒット率も確認できます

他ツールと併用し、落ちにくい体制を作る

駒澤　当社ではCloudFrontに加え、他ツールと併用してアクセスが増えるタイミングや流入元を探ったり、ユーザにLINE通知やプッシュ通知するリンク先が負荷が高いページでないかを確かめたりし、サービスが落ちないための対策をいくつか提案させていただいています。サービスのKPIとしてアクセス数を掲げる企業は多いですが、一方で「大量アクセスをインフラがさばけるかどうか」という視点を見失いがちです。

例えばLINE通知するリンク先は静的なLP（ランディングページ）にするのがおすすめです。オリジンサーバへの負荷が高いページに直接誘導すると、サーバダウンに繋がることがあります。詳しい情報が欲しい人だけを適切に誘導し負荷を分散できれば、サーバダウンやレスポンス低下による機会損失をなくすことができます。

駒澤 皓さん：北海道大学大学院卒業後、2014年11月にアイレットにてインフラエンジニアとしてキャリアをスタートする。主にスポーツメディア系サイトを担当し、スポーツイベント時にはスパイクアクセスへの対処、リソースの増減に合わせた構成の変更を行う。絶対にサーバを落とせない戦いに尽力する。好きなAWSサービスはCloudFront。

意図せぬキャッシュでの情報漏洩に注意

――CloudFrontを利用する上で気を付けるべきポイントはありますか？

駒澤　キャッシュ設定の方針を定めておくことが肝心です。

特に重要となる設定がDefault Cache Behaviorとなります。CloudFrontのCache Behaviorは特定のURLパスパターンに応じて設定を追加していきます。特定のURLパスパターンに該当しない場合には、Default Cache Behaviorの設定で処理されます。Default Cache Behaviorの設定をキャッシュ有効・無効するのかは、WEBサイトのサービス内容によります。以下の要素を参考に判断するといいのではないでしょうか。

• Default Cache Behaviorキャッシュ無効に適しているサービス：動的コンテンツがあるWebサイト/個人情報を扱うWebサイト

• Default Cache Behaviorキャッシュ有効に適しているサービス：静的コンテンツのみのWebサイト

特に注意が必要になるのが、サービス運用中に新規追加されるコンテンツです。新規コンテンツのキャッシュ設定が漏れる可能性があります。個人情報を取り扱うならば、キャッシュ設定漏れによるサーバダウンよりも情報漏洩のリスクを避けるためにDefault Cache Behaviorはキャッシュをしない設定にすることを推奨します。また、静的なLPならばDefault Cache Behaviorをキャッシュをさせ、キャッシュ設定漏れによるサーバダウンを防ぐ方針にするといいでしょう。

正しく動作しているかを確かめるには、本番環境だけでなく、開発環境にもCloudFrontを構築するのがいいでしょう。AWS WAF（Webアプリケーションファイアウォール）を利用して制限をかければクローズドな開発環境を作れます。

総括

――最後に、AWSをこれから使おうという方や、初心者の方へメッセージをお願いいたします。

栄野川・和田・駒澤　オンプレミスの経験がなくても、AWSなら簡単に自分のサイトを作ったりホスティングしたりできるのでぜひ一度使ってみてください。使っていくうちにAWSの全容がつかめてきて、ユーザさんそれぞれが「やりたい」と思ったことが実現できるようになるはずです。

そして大事なのは、情報の取捨選択を正しく行うことです。AWSサービスは2010年以降から普及しはじめたこともあり、ネットでは公開が数年前という古い記事も多く見られます。これらの情報はあくまで参考程度に留め、まずは公式ドキュメントを確認しましょう。また、自ら検証して裏取りをすることも大切です。

編集：薄井千春（ZINE）