新機能体験！RAMによる権限管理とAutoScalingによるサービス継続性の実現

SBクラウド株式会社プロダクト技術部

2017年4月21日 セミナー資料RAM AutoScaling

本日のアジェンダ

1. オープニング

2. RAM紹介a. サービス概要、ユースケース

3. AutoScaling紹介a. サービス概要

b. デモンストレーション

c. AutoScalingをうまく使う方法

4. 質疑応答

5. クロージング

（新サービス）

襲使徒 来、

新サービス

RAM (Resource Access Management)

RAMは権限の制限されたサブアカウントを作成することで、コンソール・APIへのアクセ

ス権限を制御するプロダクト。

サブアカウント単位で操作できるサービスと操作を指定することで、必要最小限な権限

の委譲を実現。サブアカウント単位でコンソールログイン制御（MFA含む）、API KEY作

成を行うことも可能。

RAMの主な機能

リソースオーナー（rootアカウント）から権限委譲されたサブアカウント（RAMアカウント）を設定可能

1つのrootアカウントに対して、最大100個のサブアカウントを設定可能

グループによる権限設定が可能

一時的に有効なアクセスキー

を実現（STS機能）

API連携のセキュリティリスクを

低減

アプリケーションとの連携によ

り、IoT機器等からOSS等クラ

ウドリソースへの安全なアクセ

スを実現

サブアカウント管理 リソースアクセス制御

サブアカウント毎に操作可能

なリソース（ECS、OSS等）を制

限可能

詳細設定では、リソース単位

の操作制限（特定のECS、特

定のOSSバケット等）が設定可

能

MFA / API KEY

サブアカウント毎にMFA設定

が可能

サブアカウント毎にAPIアクセ

スキーが設定可能

特定用途のシステム連携を安

全に構築可能（※）

一時アクセス制御

※設定例特定のOSSバケットにデータアップロードのみ可能なRAMアカウントのAPIキーをIoTデバイスに割り振ることで、必要最低限なアクセス権の設定が可能

AutoScalingトラフィック他により変動するシステムの負荷要求や、時間帯ごとに変化する処理能力

の要求に対応するために、ECSの台数を自動的に増減するサービス。ECS利用料の適

正化とコンピューティングリソース増減の運用コストを低減。

AutoScalingの適応範囲

数量

スペック

高

低

多少

スケールアップ・ダウン

スケールイン・アウトAuto Scalingの対応範囲

Cloud Monitorサービスと連動することで、ECSサーバーのCPU負荷に応じてECSサーバーの追加・削除

トラヒックの変動に対応したコンピューティングリソースの配備を自動化

ECS追加・削除トリガーア

クションを手動実行可能

（コンソール、API対応）

コンピューティングリソー

スの拡大・縮小を安全に

実行可能

動的ECS台数変更 時刻契機ECS台数変更

時刻契機でECSサーバー

の追加・削除

夜間バッチ処理や日中業

務処理負荷への対応な

ど、時間帯によるコン

ピューティングリソースの

変更を自動化

ヘルスチェック

ECSヘルスチェック機能を

具備

動作不良ECSを検知する

と、自動的に新規ECSを

追加起動

サービス提供に必要なコ

ンピューティングリソース

を自動的に維持

手動制御

AutoScalingの主な機能

動的スケールの場合の処理の流れ

CloudMonitor

AutoScaling

ECS群

①リソース監視

②閾値超えるとアラーム発報

アラーム③アラームをトリガーにAutoScaling実行

④ECSの追加

SLB(ServerLoadBalancer)

AutoScaling デモンストレーション

本日のデモ内容

● AutoScalingの設定方法

● ECSへ負荷をかけてスケールアウト

● ECSの負荷をへらしてスケールイン

AutoScalingの設定項目

スケーリング設定

スケーリングルール

時刻設定モード

動的モード(CloudMonitor連携)

Database

SLB

スケーリングアクティビティ

紐付けするRDS、SLBの選択

追加・削除するECSの数量を定義

カスタムモード

スケーリングトリガータスク

スケーリングルールを実行するためのトリガータスクの定義

タスクの実行結果

スケーリンググループ

クローンするECSの選択

スケーリングルールを実行

AutoScaling利用時の課題

● AutoScalingを利用した場合、サーバ台数の増減が自動的

に行われます。

● そのため、いつサーバが削除されるかわかりません。

● スケールしたサーバに重要な情報を保持していると、重要な

情報を失ってしまう可能性があります。

ステートレス

● AutoScalingを活用するサーバはステートレスを推奨。

永続化されるべきデータは、サーバ上で保持しない。○ 例えばセッション情報

○ ログ情報

○ ユーザのアップロードしたファイル

● 複数のサーバ間でデータを同期する仕組みも回避すべき。

AutoScalingを使った、悪い構成例

ECS・WordPress本体・画像ファイル・アクセスログ・MySQL

データ同期 データ同期

WordPressを使ったWebサイトの例

ログ情報、DB情報などすべてをAutoScaling対象のサーバで管理。

SLB(ServerLoadBalancer)

AutoScalingを使った、良い構成例

アクセスログや全てのサーバに共通の画像ファイルは外部ストレージに保存

データはWebサーバと切り離したDBサーバに保存

SLB(ServerLoadBalancer)

WordPressを使ったWebサイトの例

ECS・Apache・WordPress

OSS(Object Storage) ・アクセスログ ・画像データ

ApsaraDB for RDS ・MySQL

質疑応答セッション