キーペア、スケーリング、負荷分散、エッジ環境――“今どき”の「サーバ運用に必要な技術」超入門：AWSで学ぶクラウド時代のサーバ＆ストレージ基礎知識（4）
これまであまり物理的なサーバとストレージに触れてこなかった方を対象に、AWSを用いてサーバとストレージの基礎知識を解説する連載。第4回は、AWSの活用に欠かせない「サーバ運用に必要な技術」を詳しく解説します。
本連載「AWSで学ぶクラウド時代のサーバ＆ストレージ基礎知識」は、これまで仮想マシン（Virtual Machine：VM）は使っていたけど物理的なサーバに触れてこなかったエンジニアやサーバ管理者、情報システム部門担当者（情シス）などを対象に、サーバとストレージの基礎知識を「Amazon Web Services」（AWS）の操作を例に解説しています。
本連載は全7回の予定で、各回は下記のテーマで基礎知識を解説して、テーマに関連するAWSのサービスを紹介していきます。
連載4回目となる今回は、「サーバ運用に必要な技術」を紹介します。前回（第3回）では仮想マシンを作成しましたが、実際にサーバを運用する際には、セキュリティ対策やスケーリングなども考慮しなければなりません。また、顧客によっては、IT環境の全てをデータセンターやクラウドで管理できないケースもあります。今回はその一例として、以下の3つを詳しく解説します。
- 安全な接続を実現する認証（キーペア）
- 大規模環境におけるスケーリングおよび負荷分散
- エッジ環境における仮想化
安全な接続を実現する認証（キーペア）
クラウド上に作成された仮想マシンには、「SSH」（Secure Shell）などでリモートアクセスして運用することになりますが、この際に気を付けなければならないのが“セキュリティ”です。
パスワード認証でアクセスする場合は、パスワードの使い回しや単純なパスワードを使ってしまったことで漏えいし、第三者にログインされてしまうといったリスクが存在します。そうした事態を防ぐため、よりセキュアにリモートアクセスする方法として「公開鍵認証」を使うケースがあります。
公開鍵認証では、誰でも入手可能な鍵である「公開鍵」と、鍵作成者のみが保持する「秘密鍵」と呼ばれる2種類の鍵（キーペア）を使って認証します。
管理者は公開鍵と秘密鍵を作成し、作成した仮想マシンに公開鍵を登録し、自身のクライアント端末側で秘密鍵を保持します。仮想マシンにアクセスする際にはID／パスワードではなく、秘密鍵を持っているかどうかでログインの可否が判断されます。仮にID／パスワードが分かっていても、秘密鍵を所持している端末以外からはアクセスできないため、セキュリティが向上します。
キーペアを使う際の注意点は、秘密鍵を持っていない端末からはログインできないことと、秘密鍵を所持している端末が故障したり、紛失したりした際にはリモートアクセスできなくなるため、コンソールを使って対処する必要があることです。
大規模環境におけるスケーリングおよび負荷分散
実際に仮想化基盤上でサービスを稼働させる場合は、複数ユーザーからのアクセス負荷に対応する必要があります。その際には、サービス品質の劣化を防ぐために「スケーリング」や「負荷分散」といった手法が用いられます。
スケーリング
ユーザー数の増加に伴う負荷増への対応として、仮想マシンの性能を向上させる「スケーリング」があります。スケーリングには「垂直スケール」と「水平スケール」の2種類があり、状況に応じて使い分けます。
垂直スケールは、仮想マシンの性能自体を負荷に応じて変化させる方法です。性能を上げることを「スケールアップ」、性能を下げることを「スケールダウン」と呼びます。メリットとしては、CPUやメモリなどのスペックを変化させるため、仮想化基盤では設定が容易なこと、OSやアプリケーションを変更することなく設定できる点が挙げられます。しかし、物理サーバに搭載できるCPUやメモリの性能限界や、1台のサーバに負荷が集中するため、障害時のリスクなどは増加します。
水平スケールは、性能の変化に応じて仮想マシンの台数を増減させる方法です。仮想マシンの台数を増やすことを「スケールアウト」、台数を減らすことを「スケールイン」と呼びます。垂直スケールとは異なり、仮想マシンの台数に応じて物理サーバのスペックを上げたり、台数を増やしたりできるので、性能向上の限界がありません。また、1台が故障しても、残りの仮想マシンで処理できるのでサービスが完全に止まることを防げます。
しかし、単純に台数を増やすだけではユーザーの振り分けができず、アクセスが偏ることがあるため、単純に水平スケールだけで対処するのではなく「負荷分散」と組み合わせるのが一般的です。そのため、垂直スケールよりは設定が複雑になります。
負荷分散
水平スケールする際、負荷の集中を防ぐには負荷分散が必要と説明しましたが、そのための装置が「ロードバランサー」です。今回は複数のWebサーバを立て、ユーザーがアクセスしてきた場合を例に説明します。
まず、ロードバランサーに仮想的なIP（VIP）を設定し、ユーザーはそのVIPにアクセスします。ロードバランサーはアクセスしてきたユーザーを、Webサーバの状況を加味して振り分けます。例えば、リソース状況を見て負荷の少ないWebサーバに振り分けたり、メンテナンス中や障害で停止しているWebサーバにアクセスさせないようにしたりできます。
ロードバランサーによる負荷分散には「レイヤー4負荷分散」と「レイヤー7負荷分散」があります。レイヤー4負荷分散は、トランスポートレイヤーで動作し、TCP/UDPなどを使い、ポートやIPアドレスに対して単純に負荷を分散します。
レイヤー7負荷分散は、アプリケーションレイヤーで動作し、HTTP/HTTPなどを使い、URL、Cookie、HTTPヘッダなどで、より細かく負荷を分散できます。例えば、URLに国情報（jp、enなど）を使ってアクセスするサーバを振り分けたり、Cookie情報を基に割り振り先を固定したりするなど、レイヤー4負荷分散よりも高度な負荷分散が可能です。
エッジ環境における仮想化
多くのユーザーがデータセンターで仮想化技術を使い、リソースの効率化と運用効率化を進めていますが、全てのIT基盤をデータセンターに閉じることができないケースなどもあります。
昨今は、支社や工場、小売店舗といったデータセンターから離れた拠点（エッジ）でセンサーやカメラで取得した情報をAI（人工知能）処理させるなど、エッジ側のデータ量が増えています。増えるデータを全てデータセンター側で処理させると、遅延やセキュリティリスク、コスト増などの課題が出てくるため、エッジ側にデータを処理させる「エッジコンピューティング」基盤の活用も検討されています。
その際、エッジにアプリケーションごとに専用のハードウェアを用意すると、管理項目が増えてしまいます。また、複数拠点で同じ構成にすることを考えるとさらに運用負荷が増加します。運用負荷増を抑えるには、データセンター側で物理サーバを仮想化したのと同様、エッジでも仮想化でハードウェア台数を削減し、データセンターと同じアーキテクチャで基盤を管理することが有効です。
さらに、昨今ではエッジ基盤上へのアプリケーション配布、エッジ基盤の運用を中央管理するエッジ基盤向けオーケストレータ製品も登場しており、エッジにおける展開高速化と運用負荷削減が進んでいます。
AWSでの「サーバ運用に必要な技術」の実現方法
今回紹介した「キーペア」「スケーリング」「負荷分散」「エッジ環境」は、オンプレミスの仮想化基盤だけでなく、パブリッククラウドでも必要になる要素です。以下では、AWS環境でどのように実現するかを紹介します。
キーペア
本連載第1回の「Amazon EC2インスタンスの作成手順」でも紹介しましたが、EC2インスタンスを作成する際にキーペアを設定することで、EC2インスタンスに対して安全にリモートから接続できるようになります。
AWSでキーペアを作成するには、GUI（グラフィカルユーザーインタフェース）ツールで「キーペア名」「キーペアのタイプ」「プライベートキーファイル形式」を指定するだけです。作成したキーペアをEC2インスタンス作成時に選択するだけで、EC2インスタンスに公開鍵を組み込めるため、ユーザーが手動でOSの設定を変更することなく簡単に実装できます。
| 項目名 | 設定内容 | |
|---|---|---|
| キーペア名 | テキスト入力 | |
| キーペアのタイプ | RSA | |
| ED25519 | ||
| プライベートキーファイル形式 | .pem（OpenSSHで接続用） | |
| .ppk（PuTTYで接続用） | ||
| AWSにおけるキーペア作成時の設定項目 | ||
スケーリング
AWS環境のスケーリングでも基本的な考え方は同じで、垂直スケーリングと水平スケーリングで負荷状況に応じてリソースを変更します。
AWSでの垂直スケーリングは、単純に「インスタンスのタイプ」を変更するだけです。インスタンスタイプの変更は、本連載第3回の「Amazon EC2（Elastic Compute Cloud）インスタンスの運用」で紹介していますが、インスタンスを停止してインスタンスタイプを変更するだけでリソースの増減が可能です。
オンプレミスの仮想化ソフトウェアとは違い、特定の項目のみ変更することはできませんが、ハードウェアの世代やスペック自体を容易に変更できる点は、AWSにおける垂直スケーリングのメリットです。
AWSでの水平スケーリングは、本連載第3回で紹介した「AMI（Amazon Machine Image）を使ったクローン」で、同じ構成の仮想サーバを複数台用意します。しかし、AMIだけを利用した場合は作成や削除などが手動になり、負荷状況によって作業が発生すると運用の負荷が増加してしまいます。
こうした運用の負荷を減らすため、AWSでは条件に応じて自動的にスケールアウト／スケールインを実施する「Amazon EC2 Auto Scaling」が利用可能です。
Amazon EC2 Auto Scalingを使用する際には、EC2インスタンスのグループ「Auto Scaling group」を作成します。Auto Scaling groupには以下の設定が可能で、設定に応じてインスタンス数の増減が自動化されます。
- 最小サイズ
- 最大サイズ
- 希望する容量
今回は例として、最小サイズ「2」、最大サイズ「8」、希望する容量「4」を設定した場合の動作で解説します。まずは、設定した容量「4」でEC2インスタンスが起動します。負荷に応じて、最小「2」から最大「8」の間で自動的にインスタンスが起動／停止します。
次に、Auto Scaling groupに設定したインスタンスの範囲で、どのように変動させるのか「スケーリングポリシー」で条件を与えます。使用できるスケーリングポリシーは以下の通りです。
| スケーリング種類 | スケーリング条件 |
|---|---|
| 静的スケーリング | 常に希望する容量を維持する |
| 静的スケーリング | 設定した日時になったら台数を変化させる 例：○月△日×時になったら2増加 |
| 動的スケーリング（ターゲット追跡） | メトリクスが指定した状態になるように台数を変化させる 例：平均CPU負荷が50％になるように増減 |
| 動的スケーリング（ステップ） | アラームメトリクスが設定した複数の条件に応じて台数変化させる 例：CPU負荷が50〜70％で2増加、70〜80％で4増加 |
| 動的スケーリング（簡易） | アラームメトリクスが指定した値に達したら台数を変化させる 例：CPU負荷が50％になったら2増加 |
| 予測スケーリング | 過去14日間のメトリクスデータを分析した結果を基に台数を変化させる |
| AWS Auto Scalingで使用できるスケーリングポリシー | |
負荷の傾向が明確に分かっている場合や突発的な負荷の変化に備えるなど、状況に応じてスケーリングポリシーを使い分け、自動的にインスタンス数を増減させることでサービスの品質を維持できるようになります。
負荷分散
AWSの負荷分散サービスとしては「ELB（Elastic Load Balancing）」があります。ELBはAWSで最初に実装された負荷分散サービスですが、現在はさまざまな要件に対応するため「ALB（Application Load Balancer）」「NLB（Network Load Balancer）」「GLB（Gateway Load Balancer）」「CLB（Classic Load Balancer）」という4種類に分かれています。
・ALB（Application Load Balancer）
ALBは、HTTPやHTTPSプロトコルのレイヤー7で動作するロードバランサーです。特定の条件に基づいてトラフィックを振り分けられ、高可用性とスケーラビリティを提供します。主にAmazon EC2で作成したWebアプリケーションやサービスのフロントエンドなどで利用されます。
・NLB（Network Load Balancer）
NLBは、TCPやUDPプロトコルのレイヤー4で動作するロードバランサーです。1秒間に数百万件のリクエストを処理でき、高いスループットと低遅延が求められるアプリケーションや突発的で不安定なトラフィックへの対応が必要な環境で利用されます（ビデオストリーミング、ゲームなど）。
・GLB（Gateway Load Balancer）
GLBは他のロードバランサーとは役割が異なり、AWS上にファイアウォールやIDS（Intrusion Detection System：不正侵入検知システム）など、サードパーティーの仮想アプライアンスをデプロイ（展開）したり、管理したり、スケールしたりするサービスです。展開できるアプライアンスは「Elastic Load Balancing Partners」にリストアップされており、「AWS Marketplace」から購入できます。
・CLB（Classic Load Balancer）
CLBは「EC2-Classic Networking」内に構築されたアプリケーションを対象とした、レイヤー4とレイヤー7で動作する旧タイプのロードバランサーです。「Virtual Private Cloud」（VPC）を使用する場合、レイヤー7トラフィックにはALB、レイヤー4トラフィックにはNLBを使うことが推奨されています。
ユーザーアクセスの突発的な増加などに対応するためには、スケーラビリティと負荷分散が必要と説明しましたが、AWSではELBとAmazon EC2 Auto Scalingの連携で対応が可能です。この連携により、Amazon EC2 Auto Scalingで作成された新規仮想サーバへ事前に設定しておいた負荷分散ルールが反映されるため、台数が動的に変化する環境の運用負荷を軽減できます。
オンプレミスの仮想化ソフトウェアでも似たようなことはできますが、物理サーバやストレージをあらかじめ用意しておく必要があるのと、ハードウェアベースのロードバランサーを使用している場合には、最大負荷に対応できるモデルの調達などが必要となるため、AWSを使用した場合よりも柔軟性が低下します。負荷の傾向などが変化しやすい環境では、AWSを利用することでサービス品質の維持と運用の効率化が望めます。
エッジ環境
AWSはクラウドのイメージが非常に強いですが、エッジ環境への対応として「AWS Outposts」「AWS Storage Gateway」「AWS Snowファミリー」「AWS IoT Greengrass」といったサービスを提供しています。
AWS Outpostsは、自社のデータセンターまたはエッジにAWSのラックまたはサーバを設置し、オンプレミスでもAWSを拡張して使用できるサービスです。
「AWS Outpostsラック」は、利用時にAWSと同じスペックのサーバが搭載された42Uラックが配送されてきます。設置作業などはAWSが行うため、電源とネットワークさえ用意すればオンプレミスでAWS基盤を構築できます。ラックごと送られてくるので、小規模な拠点や工場というよりは、AWSから見たらエッジとなる自社データセンター上で高速処理などが必要な場合などでの利用となります。
「AWS Outpostsサーバ」は、1Uまたは2Uのサーバが配送されてきます。AWS Outpostsラックと違い、サーバはユーザー自身が設置します。AWS Outpostsラックよりも小規模な拠点や工場などでの利用が想定されていますが、AWS Outpostsラックよりもサポートされているサービスが少なくなります。
利用する環境に応じてAWS OutpostsラックとAWS Outpostsサーバを使い分け、オンプレミスにAWS環境を拡張しエッジコンピューティングを実現します。
AWS Storage Gatewayは、オンプレミス環境とAWSのクラウドストレージを接続するサービスです（詳細は第7回で解説予定）。オンプレミス側のアプリケーションサーバがAWSのストレージに直接アクセスするのではなく、オンプレミス側にStorage Gateway仮想アプライアンスを設置して通信させます。頻繁にアクセスするデータに関してはオンプレミス側でキャッシュすることで、低いレイテンシと高いパフォーマンスを実現します。クラウドストレージを使用できるので容量の心配も不要になり、AWSのストレージサービスのメリットをそのままオンプレミスやエッジに提供できます。
AWS SnowファミリーはAWSが提供するデータ転送用のデバイスで、データセンター外やネットワークが不安定な場所に設置します。「AWS Snowcone」「AWS Snowball」の2種類があります。以前は「AWS Snowmobile」というトラックでデータをAWSに輸送するモデルもありましたが現在はサービス終了しています。
AWS SnowconeはAWS Snowファミリーの中で一番小規模用のデバイスで、持ち運びも可能な大きさです（長さ9インチ×幅6インチ×高さ3インチ、重さ23.1キロ）。ストレージ容量はHDDが8TB、SSDが14TBで、データをオフラインもしくはオンラインでAWSに転送します。
AWS SnowballはAWS Snowconeよりも用途が広がり、ストレージ用とコンピュート用の2種類があります。「AWS Snowball Edge Storage Optimaized」はローカルストレージや大規模データ転送用で、ストレージ容量も80TBもしくは210TBです。「AWS Snowball Edge Compute Optimized」は、ネットワークに接続できない環境での機械学習や動画分析がユースケースとなるモデルです。ストレージ容量は28TBですが、vCPU（仮想CPU）とメモリのスペックが高くなっています。
AWS IoT Greengrassは、「AWS IoT」の機能をエッジ側にオフロードさせるエッジコンピューティングサービスです。AWS OutpostsやAWS Snowファミリーのような専用デバイスではなく、要件を満たしたデバイス上に構築可能です。ユースケースとしては昨今注目されている「エッジAI」などがあり、センサーなどで収集したデータをAWS IoT Greengrass上にため込んで、学習済みモデルで推論させるといったことが可能です。たまったデータはAWS IoT Greengrassから必要な情報だけをAWSにアップロードし、学習モデルを修正して、修正済みの学習モデルをAWS IoT をGreengrassに配布するといったこともできます。
このようにAWSでは、エッジ環境で活用するために複数のサービスや専用ハードウェアを提供しています。クラウドとエッジで同じアーキテクチャで一元的に運用できることが、AWSの大きな強みになります。
まとめ
今回は、サーバ運用に必要な技術として以下の3点に関してご紹介しました。
- 安全な接続を実現する認証（キーペア）
- 大規模環境におけるスケーリングおよび負荷分散
- エッジ環境における仮想化
また、これら技術がAWSでどう利用できるのかを紹介しました。次回は、「ファイルストレージ」に関してNAS（Network Attached Storage）の基礎とAWSにおけるファイルストレージサービスを紹介します。
筆者紹介
小林 浩和
ネットワンシステムズ ビジネス開発本部 応用技術部 クラウドインフラチーム
2011年にネットワンシステムズに新卒として入社。仮想化製品を中心としたクラウドインフラ全般の評価、検証、そして案件サポートを主な業務として担当。近年ではエッジコンピューティングやAI（人工知能）など先進技術に関する調査および検証業務にも従事している。
Copyright © ITmedia, Inc. All Rights Reserved.