Amazon Transcribeを調べてみた

Amazon Transcribeとは

Amazon Transcribeは一言で言うと”Speech to Text”と呼ばれる、音声をテキスト情報に変換するサービスです。
話されている言語を機械学習の技術で識別し、テキスト情報に変換します。

この技術は以下のような新しいサービスやプロダクトの提供に役立ちます。

  • 映像ファイルから音声を認識し、クローズドキャプションを生成
  • コールセンター業務などでの問い合わせ内容の分析
  • 医療分野や法律分野での活用

また、”Amazon Translate”や”Amazon Polly”と連携して、生成したテキスト情報を翻訳し、再度翻訳した言語で音声に変換することなどもできます。

何ができるのか

Amazon Transcribeには以下の3つのオペレーションがあります。

  • StartTranscriptionJob : 非同期で音声をテキストに書き起こす
  • ListTranscriptionJobs : 開始された音声認識ジョブのリストを返す。 返して欲しいJobをステータスで絞り込むことができる
  • GetTranscriptionJob : 音声認識の結果を返す。結果にはJSON形式に変換された結果へのリンクが含まれている

Speech Input

インプットするファイルはS3 bucketに保管されている必要があります。
インプットファイルの仕様は以下のみ

  • FLAC、MP3、MP4、WAV
  • 尺は2時間未満

言語、フォーマット、サンプリングレートを指定する必要があります。

  • PCM 16ビットエンコーディングのFLACやWAVなどのロスレスフォーマットを使用。
  • サンプリングレートは8000 ~ 16000Hz

Amazon TranscribeのS3とその中のファイルへのアクセスを許可する必要があります。

Output JSON

Jobが完了するとJSONが含まれた結果が生成され、テキストファイルがS3に置かれます。
ファイルのIDはユーザー固有のURIとなっており、そのURIを利用することで結果を取得できます。

Ex)

 {
      "jobName":"job ID",
      "accountId":"account ID",
      "results": {
         "transcripts":[
            {
               "transcript":" that's no answer",
               "confidence":1.0
            }
         ],
         "items":[
            {
               "start_time":"0.180",
               "end_time":"0.470",
               "alternatives":[
                  {
                     "confidence":0.84,
                     "word":"that's"
                  }
               ]
            },
            {
               "start_time":"0.470",
               "end_time":"0.710",
               "alternatives":[
                  {
                     "confidence":0.99,
                     "word":"no"
                  }
               ]
            },
            {
               "start_time":"0.710",
               "end_time":"1.080",
               "alternatives":[
                  {
                     "confidence":0.874,
                     "word":"answer"
                  }
               ]
            }
         ]
      },
      "status":"COMPLETED"
   }
 

始め方

始めるにはAWSアカウント、ID、IAMユーザーが必要です。CLIの利用も可能です。

Step.1 AWSアカウント設定

いつも通りなので割愛

Step.2 CLI設定

いつも通りなので割愛

Step.3 コンソールでの利用開始

Jobの作成

1.各種情報の入力
 - Transcription job name : AWSアカウント毎にユニークである必要がある
 - Amazon s3 input URL: 音声ファイルが格納されているS3 busket。Transcribeと同一リージョンである必要がある
 - Language:インプットファイルの言語を選択
 - Format:インプットファイルのフォーマットを選択
 - Media sampling rate(Hz):インプットファイルのサンプリングレートを8000 ~ 48000Hzの間で指定。8000~16000Hzが推奨
2.「Create」を押す

Jobの確認

Jobのリストを表示。「Availability」にサーバーに結果が保管される残り期間が表示される。結果の保管期間は90日
Jobをクリックすると、詳細(Job名、残りの保管期間、I/OのファイルのS3パス)と結果の文字列が表示される。
「Code Samples」で該当JobについてのJSONファイルを取得可能

Step.4 API

CLI

Transcribeのテストをする場合

1.InputファイルをS3 バケットに配置する(Transcribeと同じリージョンに)
2. ファイル情報を含んだJSONファイルを作成する

{
    "TranscriptionJobName": "request ID", 
    "LanguageCode": "en-US", 
    "MediaFormat": "wav", 
    "Media": {
        "MediaFileUri": "https://S3 endpoint/test-transcribe/answer2.wav"
    }
}

3.下記コマンドを実行
json
aws transcribe start-transcription-job
--endpoint-url endpoint
--region region
--cli-input-json file://test-start-command.json

・下記レスポンスが返れば成功
“`json

{
“TranscriptionJob”: {
“TranscriptionJobName”: “request ID”,
“LanguageCode”: “en-US”,
“TranscriptionJobStatus”: “IN_PROGRESS”,
“Media”: {
“MediaFileUri”: “https://S3 endpoint/test-transcribe/answer2.wav”
},
“CreationTime”: timestamp,
“MediaFormat”: “wav”
}
}
“`

Jobのリストを取得

1.Jobが完了していた場合、下記コマンドでステータスを取得する

aws transcribe get-transcription-job-results 
   --endpoint-url endpoint 
   --region endpoint 
   --request-id "DocTest-01"

・成功すればレスポンスは下記通り返ってくる

{
    "TranscriptionJob": {
        "TranscriptionJobName": "request ID",
        "LanguageCode": "en-US",
        "TranscriptionJobStatus": "COMPLETED",
        "Media": {
            "MediaFileUri": "input URI"
        },
        "CreationTime": timestamp,
        "CompletionTime": timestamp,
        "Transcript": {
            "TranscriptFileUri": "output URI"
        }
    }
}
```json

2.Output URIを使って翻訳されたテキストを取得

```json
{
      "jobName":"job ID",
      "accountId":"account ID",
      "results": {
         "transcripts":[
            {
               "transcript":" that's no answer",
               "confidence":1.0
            }
         ],
         "items":[
            {
               "start_time":"0.180",
               "end_time":"0.470",
               "alternatives":[
                  {
                     "confidence":0.84,
                     "word":"that's"
                  }
               ]
            },
            {
               "start_time":"0.470",
               "end_time":"0.710",
               "alternatives":[
                  {
                     "confidence":0.99,
                     "word":"no"
                  }
               ]
            },
            {
               "start_time":"0.710",
               "end_time":"1.080",
               "alternatives":[
                  {
                     "confidence":0.87,
                     "word":"answer"
                  }
               ]
            }
         ]
      },
      "status":"COMPLETED"
   }

SDK for Python(Boto)

・InputファイルをS3 バケットに配置する(Transcribeと同じリージョンに)。ファイル情報を含んだJSONファイルを作成する

from __future__ import print_function
import time
import boto3
transcribe = boto3.client('transcribe')
job_name = "job name"
job_uri = "https://S3 endpoint/test-transcribe/answer2.wav"
transcribe.start_transcription_job(
    TranscriptionJobName=job_name,
    Media={'MediaFileUri': job_uri},
    MediaFormat='wav',
    LanguageCode='en-US'
)
while True:
    status = transcribe.get_transcription_job(TranscriptionJobName=job_name)
    if status['TranscriptionJob']['TranscriptionJobStatus'] in ['COMPLETED', 'FAILED']:
        break
    print("Not ready yet...")
    time.sleep(5)
print(status)

・成功すればレスポンスは下記通り返ってくる

 {
      "jobName":"job ID",
      "accountId":"account ID",
      "results": {
         "transcripts":[
            {
               "transcript":" that's no answer",
               "confidence":1.0
            }
         ],
         "items":[
            {
               "start_time":"0.180",
               "end_time":"0.470",
               "alternatives":[
                  {
                     "confidence":0.84,
                     "word":"that's"
                  }
               ]
            },
            {
               "start_time":"0.470",
               "end_time":"0.710",
               "alternatives":[
                  {
                     "confidence":0.99,
                     "word":"no"
                  }
               ]
            },
            {
               "start_time":"0.710",
               "end_time":"1.080",
               "alternatives":[
                  {
                     "confidence":0.87,
                     "word":"answer"
                  }
               ]
            }
         ]
      },
      "status":"COMPLETED"
   }

認証とアクセスコントロール

・AWS Transcribeの利用にはCredentialが必要です。Credencialには認証とアクセスコントロールの設定を行う必要があります。

認証

・認証には以下のいずれかを使用します。
– AWS Account ルートユーザー(非推奨)
– IAM role
  (1) ユーザーごとの許可
  (2) AWSサービスのからのアクセス
  (3) EC2からのアクセス許可

アクセスコントロール

TranscribeへアクアセスするためのPermissionの管理

アクセスとアクションの確認

・誰が何にアクセスするかはは下記方法で定義します。
 - IAMポリシー:IAMユーザーやIAM roleに権限を付加する
 - リソースベースのポリシー:各AWSのサービスにAPIでアクセスする際に要求されるポリシー主にResource,Action,Effect,Principalなど

TranscribeのためのIAM ポリシー

・StartTranscriptionJobを実行するためのIAM roleの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "transcribe:StartTranscriptionJob"
             ],   
            "Resource": "*"
        }
    ]
}

・コンソールでTranscribeを使用するためのIAM roleの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "transcribe:*"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

・音声を取得するためにIAM roleの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "transcribe.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::bucket name/*"
        }
    ]
}

・KMSを使ったS3の暗号化を行うための IAM roleの例

{
      "Sid": "Allow-Transcribe",
      "Effect": "Allow",
      "Principal": {
        "Service": "transcribe.amazonaws.com”
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }

APIに対する権限のリファレンス

・Amazon TranscribeのAPIは下記通り
 - GetTranscriptionJob:
   API: transcribe:GetTranscriptionJob
   Resource:*
 - ListTranscriptionJobs:
   API: transcribe:ListTranscriptionJobs
   Resource:*
 - StartTranscriptionJob:
   API: transcribe:StartTranscriptionJob
   Resource:*

ベータ版のガイドラインと制限

・現在は下記リージョンのみ
 -リージョン:US East (N. Virginia)
 - Endpoint::https://transcribe.us-east-1.amazonaws.com
 - プロトコル:HTTPS
・推奨素材は以下
 - ロスレスFLAC、ロスレスWAV、PCM(16ビット)
 - サンプリングレート 8000 ~ 16000Hz
・制限は以下の通り
 - 尺は最長2h

APIリファレンス

・別紙参照(https://docs.aws.amazon.com/ja_jp/transcribe/latest/dg/API_GetTranscriptionJob.html)

続きを読む

AWS RDS勉強まとめ

・RDSの制限事項
バージョンが限定
キャパシティに上限
OSログインやファイルシステムへのアクセス不可
など

上記が許容できない場合はOn EC2かオンプレミスで構築

Multi-AZ
同期レプリケーションと自動フェイルオーバー
インスタンスやハードウェア障害時など

リードレプリカ
デフォルトで5台増設可能
マルチAZやクロスリージョン対応も可能
マスタと異なるタイプに設定可能
読み取り専用などに設定し、スループット向上

・スケールアップ、スケールダウン可能

・ストレージタイプ
汎用SSD
プロビジョンドIOPS
マグネティック

・バックアップ
自動スナップショット+トランザクションログをS3に保存
1日1回設定した時間に自動スナップショット取得、保存期間は0日~35日、手動スナップショットも可能

・リストア
スナップショットをもとにDBインスタンス作成
指定した時刻の状態にすることも可能(Point-in-Time)

・スナップショットはDBインスタンスのサイズと同サイズまでコスト無料
・自動スナップショットはDBインスタンス削除と同時に削除
※手動スナップショットは削除されないので、削除前に最終スナップショットをとること推奨
・スナップショット実行時にI/Oが停止するが、マルチAZの場合はスタンバイから取得するためアプリへの影響なし

リネーム
RDSに接続する際のエンドポイントを切り替える機能
旧本番インスタンスをリネーム→新本番インスタンス(スナップショットからリストア)をリネーム

・リネームの注意点
DNSはすぐに切り替わるわけでない
CloudWatchのMetricNameは引き継がない
マスターをリードレプリカの関係、タグ、スナップショットは引き継ぐ

・RDSにかかわる制限事項
RDSインスタンス数:40
1マスターあたりのリードレプリカ数:5
手動スナップショット数:100
DBインスタンスの合計ストレージ:100TB
必要に応じて上限緩和申請

・デフォルトではDBインスタンスに対するネットワークアクセスはオフ
→セキュリティグループで制御し、アクセス許可のポートなどを指定

・DBインスタンスとスナップショットの暗号化可能

オンデマンドDBインスタンスVSリザーブドインスタンス
リザーブドインスタンス:予約金を支払うことで価格割引

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/20170510awsblackbeltrds

続きを読む

AWS EBS勉強まとめ

2017年新しい機能追加
==
・起動ボリュームの暗号化をサポート

スループット最適化HDD
高スループットを必要とするワークロード(MapReduce、Kafka、ETL処理、ログ処理、データウェアハウスなど)向けのタイプ; 1GBあたり月額0.054ドル
コールドHDD
同様のワークロードでアクセス頻度が低いユースケース向け; 1GBあたり月額0.03ドル
プロビジョンドIOPS SSD
I/O性能に依存するNoSQLデータベースやリレーショナルデータベース
汎用SSD
起動ボリューム、低レイテンシを要求するアプリケーション、開発・テスト環境
マグネティック
アクセス頻度の低いデータ
参考URL:https://aws.amazon.com/jp/blogs/news/amazon-ebs-update-new-cold-storage-and-throughput-options/

・汎用SSDボリュームのバーストクレジットの残高がCloudWatchで確認可能(残高はパーセンテージ)

・稼働中のEBSをオンラインのまま、ダウンタイムなく、変更することを可能にするエラスティックボリューム機能をリリース

・現行世代のインスタンスに関しては下記可能
①容量の拡張
②IOPS値の変更(PIOPSボリュームのみ)
③ボリュームタイプの変更(汎用SSD→コールドHDDなど)
→CloudWatchとCloudFormationやAWS Lambdaなどで自動化も可能

参考URL:https://aws.amazon.com/jp/blogs/news/amazon-ebs-update-new-elastic-volumes-change-everything/

・EBSスナップショットにコスト配分タグをサポート
→コスト集計ができるようになった
==

・EBSスナップショットはS3に保存
・AZごとに独立。同一AZのインスタンスのみから利用可能
→しかし、Snapshotから任意のAZに復元可能
・EC2に複数のEBSを接続可能だが、反対は不可

・EBSはレプリケートされているので、冗長化は不要
・セキュリティグループによる制御の対象外。全ポートを閉じてもEBSは利用できる

・インスタンスストアVSEBS
インスタンスストア:揮発性。EC2のローカルディスク。仮想マシンが止まるとデータ消去。一時的なデータの置き場所などに利用。
EBS:永続化ストレージ。OSやDBのデータなど永続化のデータ用。

・スペックは下記の順
プロビジョンドIOPS→汎用SSD→スループット最適化HDD→コールドHDD→マグネティック

SSDの種類は下記2種類
汎用SSD
I/O機能を一時的に3000IOPSまで上げるバースト機能付き
→I/O Creditが必要。CloudWatchで監視可能。上限(540万I/Oクレジット)に対するパーセント
容量:1GB~16TB
IOPS:ベースは100IOPS。最大10000IOPS
スループット:128MB/秒~160MB/秒

プロビジョンドIOPS
容量:4GB~16TB
IOPS:50IOPS/1GB。最大20000IOPS
スループット:最大320MB/秒

HDDの種類は下記2種類
→小さいデータのランダムアクセスになりがちな処理、起動ボリューム、データベース、ファイルサーバー等への利用は非推奨
→ログ処理などのシーケンシャルアクセス用途。アクセス頻度が低いもの

スループット最適化HDD
容量:500GB~16TB
IOPS:最大500IOPS
スループット:40MB/秒がベース

コールドHDD
容量:500GB~16TB
IOPS:最大250IOPS
スループット:12MB/秒がベース

マグネティック
磁気ディスクタイプ
容量:1GB~1TB
IOPS:100IOPS
スループット:40MB/秒~90MB/秒
I/Oリクエスト回数による課金が唯一ある

EBS最適化インスタンス
EC2とEBSの独立した帯域を確保し、I/O性能の安定化

事前ウォーミング
Snapshotから復元したボリュームへの初回アクセス時に設定

・EBSのパフォーマンス改善
①EC2インスタンス側のスループット
EBS最適化を有効にする
EBSからのスループットの上限値に到達していないかをCloudWatchのVolume Read/Write Bytesの合計値で確認

②EBSが処理できるIOPS
CloudWatchのVolume Read/Write Opsを参照

③各EBSボリュームのスループット
CloudWatchのVolume Read/Write Bytesの合計値で確認

・Snapshot
EBSのバックアップ機能
S3に保管。2世代目以降は増分バックアップ。1世代目を削除しても復元可能
ブロックレベルで圧縮して保管するため、圧縮後の容量に対して課金
データ整合性を保つため、静止点を設けることを推奨
別AZに移動したい場合や、容量変更などもSnapshot経由で行う

・バックアップと静止点
EBSへのI/O停止→Snapshot作成指示→作成指示レスポンス→EBSへのI/O再開
※Snapshotの作成完了前にEBSへのI/O再開してよい

・Snapshotの削除
1世代目を削除しても、1世代目にしかないデータは削除されない

・リージョン間コピーをサポート
リージョン間でのコピーも可能

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-amazon-elastic-block-store-ebs

続きを読む

【2018年】AWS全サービスまとめ その2(開発者用ツール、管理ツール、メディアサービス) | Developers.IO

AWSのリソースおよびAWSで実行しているアプリケーションのモニタリングサービス。メトリクス(CPU使用率やネットワークI/Oなど)やログを収集し(CloudWatch Logs)、SNSやAutoScalingと連携するアラームを作成できる。またAWSリソースの変更イベントを監視し、Lambdaなどのターゲットに対して、リアルタイムに通知が … 続きを読む

MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora(MySQL互換)R4インスタンス再テスト(mysqlslap)

以前、R4インスタンスが使えるようになったときにmysqlslapで性能テストをしたので、今回、同じ条件で再度R4インスタンスだけmysqlslapしてみました。

mysqlslapの内容

前回と同じです。

mysqlslap
$ mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=mixed -u 【ユーザ名】 -h 【クラスタエンドポイント】 -p

結果

結構、衝撃的です…。
なお、暗号化の有無での性能差はわずかしかありませんでしたので、今回は暗号化ありの結果のみ掲示しておきます。
また、参考として、今回はr4.2xlargeインスタンスの結果も加えておきます。

実施時期 r4.large・バイナリログなし r4.large・バイナリログあり r4.xlarge・バイナリログなし r4.xlarge・バイナリログあり r4.2xlarge・バイナリログなし r4.2xlarge・バイナリログあり
前回(2017/10/末・Ver.1.15) 48.860 57.737 33.133 37.857
今回(2018/01/上・Ver.1.16) 74.779 91.679 45.433 54.413 34.180 39.621
性能比 65.3% 63.0% 72.9% 69.6%

※単位は秒。すべて暗号化ありの結果。

ちょうどインスタンスタイプ1段階分ぐらい遅くなっています。
もしかして前回インスタンスタイプの指定を1段階間違えたか?と思って請求情報を見たら、間違っていませんでした。
aurora_cost.png

もちろん、クライアント側に問題がないか確認するためにクライアント側のEC2インスタンスもタイプを色々変えて試しましたが、結果は誤差の範囲でした(AZも一致していることを確認)。

ただ、実際のワークロードはmysqlslapとは違うので、プロダクト環境でどうなるかは実際の環境で確認・検証してください

※明日から私もプロダクト環境と同等のステージング環境で性能テストです…つらいことになる予感。

追記:
参考までに記しておくと、r4.large・バイナリログありの今回(2018/01/上)分がピーク時CPU使用率90~100%程度、でした。
より大きなインスタンスタイプに対しても同じ負荷を掛けて計測しているため、(ディスク/ネットワークI/O側がネックにならないと仮定すれば)インスタンスタイプが大きいほど性能低下の程度が小さい、という結果が出るのは当然といえます(r4.xlarge以上に対しては100%の負荷を掛けていないので)。


続きを読む

クラウド時代の秘密情報管理 ベストプラクティス 〜2017冬〜

リクルートライフスタイル Advent Calendar 2017、25日目を務める @tmshn です。

最近は主に飲食店検索のためのチャットボットを作るプロジェクトに参加していますが、チームのアカウントを管理するアカウントおじさんをやったりもしています。

はじめに

皆さん、チームでの秘密情報ってどうやって管理していますか?

サーバへの SSH 鍵、他チームが提供する API へのアクセストークン、DB にアクセするためのパスワード……私たちの身の回りには、管理しなくてはいけない「秘密情報」がたくさんあります。
個人が管理すべきものは各自が適切に使用・保管すればいいですが、バッチジョブが使うシステムアカウントの認証情報などは、そうはいきません。

今回は、そういったチームでの秘密情報をどうやって管理したらいいか、2017年冬時点で私たちがたどり着いたベストプラクティスをご紹介します。

なお本記事の内容は、AWS や GCP のようなクラウド上でシステムを構築していることを前提にしていますので予めご了承ください。

(昨年は学会の参加報告を書きましたが、今年もほとんどコードが出てこない長文記事になりました……)

何が悩みか

1. 誰がどの情報を持っているかをコントロールしづらい

たとえば、あるバッチジョブで使うデータベースのパスワードがあるとします。

最初にバッチを作成した Alice は、そのパスワードを知っています。しかしそれ以外は誰も知らないとしたら、それはシステムが属人化された非常に不健全な状態ですね(繰り返しますが、個人が使う秘密情報は個々人が管理すべきですよ)。

ではやっぱりチーム内で共有すべきだということになり、Alice は同僚たちにその暗号化キーをメールで送信しました。めでたしめでたし? いえ、こうなるともう、誰が知っていて誰が知らないか制御不能です。
同僚の Bob が異動することになった、Charlie がうっかり送るべきでない人に転送してしまった、など何が起きるか分かりません。

一度インターネットに上がった情報は二度と消せないという箴言もありますが、一度自分の手を離れた情報はどこまで広まるかコントロールできません(もちろん送られるべきでない人に送られてしまっているという事態はすでに重大なセキュリティインシデントですが、そういう最悪な状況も十分ありえるよね、という性悪説に立った話をしています)。

さらに厄介なことに、1つの秘密情報へのアクセス権から、他の情報が芋づる式に分かってしまうことが多々あります。現実的な例でいえば git の push 権限から CI サーバが持つ情報にアクセスできたり、コンテナレジストリの pull 権限からバッチ用イメージに埋め込まれた鍵ファイルを取得できたりなどです。

2. どのシステムがどの情報を使っているのか把握しづらい

最初に Alice がバッチジョブで使ったパスワードは、今やチーム全体で様々なバッチで使われています。

あるときそのパスワードのリークが疑われたため、データベースアカウントを再作成し、そのアカウントを使っていた全バッチで新しいパスワードを使うことになりました。……さて、では「そのアカウントを使っていた全バッチ」のリストはすぐに出せますか? というのが次に問題になることです。

候補が少なければまだ良いですが、数百とかになってくると、もう手に負えません。

また、アカウントを入れ替えたくなるのはリークが疑われたときだけとは限りません。利用場所が増えたことで付与されている権限が肥大化してしまったときなどは、より権限を細分化した複数アカウントに分割したくなるでしょう。

どう解決するか

まず大前提として、不必要な秘密情報は発行しない、という原則を意識すべきです。特にクラウドプロバイダが提供するサービスを組み合わせて使っている限りは、ほとんど不要になると思います。

たとえば AWS Lambda から DynamoDB にアクセスするためにはロールで十分なので、アクセスキーを発行する必要はありません。GCE VM インスタンスから BigQuery にアクセスるのためのサービスアカウントは直接インスタンスにアタッチできるので、鍵ファイルをダウンロードする必要はありません。

それでもどうしても必要なものをどうするか。そのソリューションが下記の2点です。

1. 情報の共有場所をクラウドのストレージサービスに固定する

共有すべき情報は、すべてストレージサービスにアップロードしてチーム内でできるだけオープンに共有してしまいます。そして、他の手段では共有しないようにします。

AWS でいえば S3、GCP でいえば GCS ですね。

そんなところに置いていいのかと一瞬不安になりますが、いずれも下記要件を満たしており、安全性は保証できます。

  • サーバサイドでの暗号化(GCS の場合はデフォルトで有効)
  • アクセスログの記録
  • バケット単位での読み書きの権限設定(S3 はもっと細かく設定できます)

これにより、誰がどの情報にアクセスできるのか・実際にアクセスしたのかが容易に管理できるようになります。

2. 情報はこまめに入れ替え、利用時取得を徹底させる

しかし上記のルールだけでは、ストレージからダウンロードした情報を誰かが持っていってしまわないとも限りません。

それを防ぐのが、こまめな入れ替え(ローテーション)です。リークが疑われたときにだけ入れ替えるのではなく、日常的に入れ替えを行うことで情報の寿命を限定します。これにより、利用者に利用時取得を徹底させることができ、また漏洩時のリスクを最小化することができます。

利用時取得というのは、文字通り秘密情報を使う瞬間にストレージから取得するということです。そのため、たとえばバッチ用 Docker イメージに秘密情報を埋め込んだりする必要がなく安全性が高まります。

考え方としては OTP などでよく使われる「30分だけ有効なトークン」と同じですね。さすがに30分毎に入れ替えるのはやりすぎだと思いますが、日次か週次くらいで入れ替えるようにするのが良いと思います。

おわりに

本記事では「誰がどの情報にアクセスできるのか」「どのシステムがどの情報を利用しているか」という秘密情報管理における関心事を、クラウドストレージでの共有とこまめな入れ替えという2本柱でコントロールできることを紹介しました。

アイデア自体はシンプルなため、正直我々も最初はこんなものがうまくいくのか半信半疑でした。しかし、しばらくこのやり方を運用してみた現在では、その簡単さ・透明性の高さ・そして強力を実感しています。

このアイデアはもともと、Google I/O に参加した同僚が現地で仕入れてきたものでした。でもあとになって気がついたのですが、実は Google Cloud Platform のブログにもほぼ同じものが紹介されていたんです。

そんなわけで、2017年冬時点で私たちがたどり着いている、秘密情報管理のベストプラクティスのご紹介でした。
もっと良いやり方や、上記のやり方への改善点をご存じの方。ぜひコメント欄などでご教示ください。

それでは皆さん、ご自愛のうえ、素敵な年末をお過ごしください。

続きを読む

新しいCloudWatch AgentでEC2インスタンスのメモリ使用率を監視する

この記事は OpsJAWS Advent Calendar 2017 19日目の記事です。

はじめに

先日、新しいCloudWatch Agentが登場しました。
https://aws.amazon.com/jp/about-aws/whats-new/2017/12/amazon-cloudwatch-introduces-a-new-cloudwatch-agent-with-aws-systems-manager-integration-for-unified-metrics-and-logs-collection/

これまでディスク使用量やメモリ使用率といった仮想マシン上のメトリックについては
CloudWatch Monitoring Scripts 等 を設定してCloudWatchにデータを送信する必要がありました。
新しい Agent ではこれらのゲストOS上のメトリックについても収集できるようになっています。

収集可能なメトリックの一覧については以下のドキュメントを参照ください。
稼働対象(EC2 or On-premises)、OS、ログ取得レベルによっても取得出来る内容が異なります。
http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html#metrics-collected-by-CloudWatch-agent

やってみる

実際にAmazon Linuxサーバのメモリ使用率の監視設定を行ってみます。

IAMロールの作成

CloudWatch Agent を実行する EC2 インスタンスにアタッチする IAM ロールを事前に作成しておきます。

まず、以下の内容でポリシーを作成します。ポリシー名は任意に設定します。

CloudWatchAgentAdminPolicy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CloudWatchAgentAdminPolicy",
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "cloudwatch:PutMetricData",
                "ec2:DescribeTags",
                "logs:DescribeLogStreams",
                "logs:CreateLogGroup",
                "logs:PutLogEvents",
                "ssm:GetParameter",
                "ssm:PutParameter"
            ],
            "Resource": "*"
        }
    ]
}

新規のEC2用のIAMロールを作成し、上記のポリシーをアタッチします。
Agent の設定は AWS Systems Manager のパラメータストアに格納し、他サーバに展開させることが可能です。
上記例ではパラメータストアへの書き込みのため、ssm:PutParameter権限を付与しています。
通常、全てのインスタンスがパラメータストアへの書き込み権限を持つ必要はありませんので、
上記とは別に ssm:PutParameter を除いた一般用のIAMロールを別途作成することが望ましいです。

image.png

CloudWactch Agent のインストール

先ほど作成したIAMロールを、インストール対象のEC2インスタンスにアタッチします。

Agent のインストール方法は以下の2通りです。

  • AWS Systems Manager(ssm)によるインストール
  • CLI によるインストール

運用を考えると ssm でインストールを行うほうが楽ですが、
今回はAgentの基本的な操作を覚えるために、EC2インスタンスにログインし、CLIでインストールを行いました。

$ wget https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip
$ unzip AmazonCloudWatchAgent.zip
$ sudo ./install.sh

プロキシを設定する必要がある環境の場合は、
/opt/aws/amazon-cloudwatch-agent/etc/common-config.tomlに設定します。

common-config.tml
[proxy]
http_proxy = "{http_url}"
https_proxy = "{https_url}"
no_proxy = "{domain}"

Agent 設定

Agent 設定ファイルの作成

Agent の設定ファイルは、収集するメトリックやログファイルを指定したファイルです。
JSONで作成されたファイルをAgent 起動時にTOMLに変換する形になります。
手動で作成することもできますが、ここではウィザードを使用して作成します。

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

ウィザードでは以下を設定します。カッコ内は今回選択した内容です。
収集間隔は最短で1秒を指定できるようになっていますが、今回は60秒を選択しました。

  • インストール先のOS(Linux)
  • インストール先がEC2かオンプレミスか(EC2)
  • ホストのメトリクスを収集するか(yes)
  • CPUコア毎のメトリクスを収集するか(yes)
  • EC2ディメンションを全てのメトリクスに追加するか(yes)
  • メトリクスを収集する間隔(60s)
  • メトリクスの収集レベル(Standard)

ログファイル監視対象の設定

既にCloudWatch Logs を使用している環境の場合は、引き続きこのウィザードで設定を移行できます。
移行を行わない場合も監視対象のログファイルのパスを指定し、追加することができます。
ここでは デフォルト選択の syslog(/var/log/messages) を対象に指定し、ログの監視設定を完了します。

設定ファイルは /opt/aws/amazon-cloudwatch-agent/bin/config.json に保存されます。
今回、最終的な設定内容は以下のようになります。

config.json
{
    "logs": {
        "logs_collected": {
            "files": {
                "collect_list": [
                    {
                        "file_path": "/var/log/messages",
                        "log_group_name": "messages"
                    }
                ]
             }
         }
    },
    "metrics": {
        "append_dimensions": {
            "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
            "ImageId": "${aws:ImageId}",
            "InstanceId": "${aws:InstanceId}",
            "InstanceType": "${aws:InstanceType}"
        },
        "metrics_collected": {
            "cpu": {
                "measurement": [
                    "cpu_usage_idle",
                    "cpu_usage_iowait",
                    "cpu_usage_user",
                    "cpu_usage_system"
                ],
                "metrics_collection_interval": 60,
                "resources": [
                    "*"
                ],
                "totalcpu": false
             },
            "disk": {
                "measurement": [
                    "used_percent",
                    "inodes_free"
                ],
                "metrics_collection_interval": 60,
                "resources": [
                    "*"
                ]
            },
            "diskio": {
                "measurement": [
                    "io_time"
                ],
                "metrics_collection_interval": 60,
                "resources": [
                    "*"
                ]
            },
            "mem": {
                "measurement": [
                    "mem_used_percent"
                ],
                "metrics_collection_interval": 60
            },
            "swap": {
                "measurement": [
                    "swap_used_percent"
                ],
                "metrics_collection_interval": 60
            }
        }
    }
}

パラメータストアへの保存

ウィザードの最後に設定ファイルをSSM パラメータストアに保存するかの確認があります。
選択肢は全てデフォルトで問題ありません。

  • 設定ファイルを SSM パラメータストアに保存するか(yes)
  • パラメータストア名(agent-config-linux)
  • 保存先リージョン(ap-northeast-1)
  • AWSクレデンシャルの選択(From SDK)

aws cliで手動アップロードすることも可能です。

$ cd /opt/aws/amazon-cloudwatch-agent/bin/
$ aws ssm put-parameter --name "agent-config-linux" --type "String" --value file://config.json

AWS Systems Manger のコンソールを確認すると、パラメータストアが保存されていることが確認できます。

image.png

Agentの起動

SSMパラメータストアに保存した設定ファイルでAgentを起動してみます。

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c ssm:agent-config-linux -s
/opt/aws/amazon-cloudwatch-agent/bin/config-downloader --output-file /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json --download-source ssm:agent-config-linux --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml
Successfully fetched the config from parameter store ssm:agent-config-linux and saved in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
Start configuration validation...
/opt/aws/amazon-cloudwatch-agent/bin/config-translator --input /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json --output /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml
Valid Json input schema.
Configuration validation first phase succeeded
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -schematest -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
Configuration validation second phase succeeded
Configuration validation succeeded
amazon-cloudwatch-agent start/running, process 2811

メッセージの内容から、JSONの設定ファイルが
/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml として保存されていることがわかります。

ログファイルは /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log に出力されています。
またAgentインストール時にサービス登録が行われていますが、

  • common-config.toml
  • amazon-cloudwatch-agent.toml

の2ファイルが存在しないと、OS起動時にAgentが正常に起動できないようです。

ステータス確認、および終了コマンドは以下のように行うことができます。
また amazon-cloudwatch-agent.toml が作成されている状態であれば、2回目以降の起動では
設定ファイルのフェッチは不要です。

# ステータス確認
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
{
  "status": "running",
  "starttime": "2017-12-19T01:43:56+0000",
  "version": "1.73.9"
}

# 停止
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a stop
amazon-cloudwatch-agent stop/waiting

# 起動
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a start
amazon-cloudwatch-agent start/running, process 3044

監視設定

コンソール上で取得したメトリックの確認および、アラームの設定を行います。

メトリックの確認

カスタム名前空間の CWAgent を選択します。
少しわかりにくいですが、それぞれのメトリックを確認できます。

  • ImageId, InstanceId, InstanceType, device, fstype, path: Disk
  • ImageId, InstanceId, InstanceType, cpu: CPU
  • ImageId, InstanceId, InstanceType, name: Disk I/O
  • ImageId, InstanceId, InstanceType: Memory

image.png

ImageId, InstanceId, InstanceType を選択すると、mem_user_percent および swap_user_percent の値を確認することができました。

image.png

アラームの設定

特に変わった手順はありません。
グラフ化したメトリクスからアクションのアラームの作成を選択します。
image.png

アラーム名、閾値、間隔、通知先等を任意に設定し、アラームの作成を押下します。
image.png

以上でメモリ使用率の監視設定が完了しました。
参考になれば幸いです。

続きを読む

Fargate の監視についての考察

この記事は AWS Fargate Advent Calendar 2017 の16日目の記事です。

概要

AWS Fargate の登場により、EC2インスタンスやそのクラスタを意識せずともコンテナが実行できるようになりました。AWSさん曰く、”コンテナをデプロイする最も簡単な方法”ということです。すごいですね。一方で、コンテナを本番環境に導入すると”9ヶ月でコンテナ数が5倍に増加する”や”仮想マシンより9倍早く縮退するようなライフサイクルで利用される”といったレポート1 もありますので、より流動的になるインフラに対して運用時の可視性を確保するためにFargateのモニタリングについて考えてみました。

AWS Fargate で利用可能なモニタリング

AWS FargateはこれまでのAmazon ECSと同様にCloudWatch Logs と CloudWatch Eventsをサポートしているので、awslogsを通じてアプリケーションやミドルウェアのログはCloudWatch Logsに転送することが可能で、Fargate タスクの状態変化はCloudWatch EventsのトリガとしてSNSトピックやLambda関数を実行できます。
CloudWatch メトリクスは非常にシンプルで、ECSではクラスタ単位のメトリクスをモニタしていましたが、それがサービス単位のCPUとメモリのメトリクスのみになります。

Fargate 運用の可視性を確保するための要素

システム上で起こりうるあらゆる事象に対して可視性を確保するうえで、必要なデータを 5W1H的な分類で整理してみると以下のようになります。WHATはグラフ化できるような数値データ、WHYはログや状態を示すイベント、HOWはアプリケーションのトランザクショントレース(APM, Application Performance Monitoring)として、WHENとWHEREについては基本的にモニタリングのデータは時系列データでありタグ等のメタデータが付属するため共通するものなので割愛してます。( 例えば、この分類で車の運転のモニタリングを考えると、WHATは速度などの計器類のデータ、WHYはドライバーの操作ログ、HOWはドライブレコーダー、という感じです。どれが欠けても事故の調査は難しくなるし、全部無い=モニタリングしない、を想像すると恐ろしいですねw )

Fargateの
モニタリング
WHAT WHY HOW
データのタイプ メトリクス ログ トレース
対応サービス CloudWatch
(メトリクス)
CloudWatch
Logs, Events
(なし)
データの種類 CPU, mem アプリ, ミドル (なし)
データの粒度 サービス単位 サービス単位,
タスク単位
(なし)

さてこうしてみると、Fargateがコンテナ環境のモニタリングにおいてトレースをサポートできていないのは痛いなぁと思うのと同時に、AWSのことだから割とすぐにX-RayがFargateをサポートするんだろなー…とか想像できます。2
また、ログのサポートが整っている一方で、メトリクスはCPUとメモリだけでディスクI/OやネットワークI/Oが無い、サービス単位だけでタスク単位では見られない、などまだ手薄感がありますが、こちらは今時点はECSのモニタリングの仕組みを流用してるからかなー、Docker Stats API のFargate版みたいなのすぐ出ますよねぇ?とか思うわけです。3

まとめ:Fargateはどうモニタリングするか

モニタリングのプロセスを分けて考えると、データ収集と保存–>可視化–>アラート–>分析–>ナレッジの蓄積、という感じになると思いますが、各プロセスについて以下のように対応を進めるのが良いかと思っています。

Fargateの
モニタリングプロセス
対応サービス メモ
データ収集と保存 CloudWatch,
Events, Logs
ログも忘れず収集する
可視化 CloudWatch
Dashboard
意外と使われていない気がするけど
便利なので使ったほうがいいと思う
アラート CloudWatch Eventsも併用する
分析 CloudWatch
Dashboard
作り込めば問題分析に使えるので
やはり使ったほうがいいと思う
ノウハウの蓄積 (なし) ポストモーテム用にDashboardの時間が
固定できればいいのになぁ

BIツールやELKスタックを利用することがかなり普及していて重要なデータを可視化することが良いとは良く知られていると思いきや、モニタリングデータの可視化はそれほど重要視されていない気がしてやった人のみぞ知る、、、となっている気がするので、手近なところでCloudWatch Dashboardは取り組んで見る価値が十分あるんじゃないかなと思います。4



  1. 「Docker採用の驚くべき8つの事実」 Datadogが毎年実施しているユーザー調査レポートです。コンテナのライフサイクルの短縮は毎年進んでいます。 

  2. これについては、本当に何も知らず想像で言っていますが、、多分そうなるでしょう。 

  3. Datadogは Fargateのローンチパートナーで3rdパーティのモニタリングツールとしてFargateのリリース時に紹介されていますが、実際このAPIが無いとdocker-dd-agentがうまく仕事出来ないので困るのです。このAPIが出た際は記事を更新します。 

  4. 可視化含めてモニタリングプロセスの劇的な改善をするのがDatadogの強みなのでご興味ある方は“無償トライアル”へGo!!,,,ご清聴ありがとうございました。 

続きを読む

AWS の TrustedAdvisorを使おう

この記事は CrowdWorks Advent Calendar 2017 の1日目の記事です。

Trusted Asvisor とは

Trusted Advisor は AWS で利用している EC2 や RDS などのサービスをコストやセキュリティに関する Best Practice に基づいたアドバイスを自動的に行なってくれるサービスです。Best Practice に関しては Web で公開されております。

https://aws.amazon.com/jp/premiumsupport/trustedadvisor/best-practices/

この機能を使うことで、普段の業務で開発用に立てたインスタンスをついそのままにしてしまった時や、甘めに設定してしまったセキュリティに関して警告を確認することができ、つい放置してしまったインスタンスが元で開発費を圧迫したりセキュリティインシデントが発生するのを軽減することができます。

プランについて

普通のAWS利用者だとしたらサポートプランをアップデートしていなければ Trusted Advisor は制限がかかっていて、セキュリティの一部項目以外は利用できない状態になっています。

01.png

すべてのチェックを行うにはビジネス以上のプランにする必要があり、料金も月 $100 以上かかってしまうので個人利用でこのプランを利用するのはかなりの決断が必要そうです。しかし会社単位で考えるとビジネス以上にすれば $100 でムダやセキュリティリスクを軽減する事ができるのでお得といえるのではないでしょうか。

おさえておきたいチェック項目

色々なチェック項目はあるのですが、おさえておきたいチェック項目は以下の項目です。

アイドル状態の Load Balancer

02.png

Load Balancer はアイドル状態でも結構課金されてしまうので、必要なければ削除しておきたいところです。

使用率の低い Amazon EC2 Instance

03.png

EC2 インスタンスは開発するときに実験で何個も立ててしまいがちです。立てるのは良いですが、消すのを忘れるということはよくあるのではないでしょうか。そういう時使用率の低いインスタンス一覧を表示してくれるので便利です。

セキュリティグループ 開かれたポート

04.png

無制限のアクセスを許可しているセキュリティグループの一覧を表示してくれるので、これを参考に必要なければ消すなりアクセスを制限するなどしていけます。基本的には制限したほうが安全ですのでここは要注意です。

Amazon S3 バケット許可

05.png

S3のバケットがグローバルに公開されている場合警告が出ます。S3 のバケットも割りとカジュアルに作ったりすることがあると思いますので、ここも確認して不要に公開されていないか確認しておいたほうが良さそうです。

コマンドラインからの利用

Trusted Advisor は他の AWS のサービスと同様に aws コマンドから利用できます。

$ aws support describe-trusted-advisor-checks --language ja

これで日本語の description のついたチェック一覧を取得できます。出力は以下のような形式です。

{
    "checks": [

        {
            "category": "cost_optimizing",
            "description": "少なくとも過去 14 日間常に稼働している Amazon Elastic Compute Cloud (Amazon EC2) インスタンスがあり、1 日の CPU 使用率が 10% 以下、かつ Network I/O が 5MB 以下である日が 4 日以上ある場合にアラートします。実行中のインスタンスに対しては 1 時間毎に使用料が発生します。設計上の考慮により意図的に稼働率を低く抑える場合もありますが、一般的にはインスタンスの台数とインスタンスサイズを調整することでコストを削減することができます。(執筆者注以下略",
            "metadata": [
                "リージョン",
                "インスタンスID",
                "インスタンス名",
                "インスタンスタイプ",
                "月間推定節約額",
                "1日目",
                "2日目",
                "3日目",
                "4日目",
                "5日目",
                "6日目",
                "7日目",
                "8日目",
                "9日目",
                "10日目",
                "11日目",
                "12日目",
                "13日目",
                "14日目",
                "14日間の平均CPU使用率",
                "14 日間の平均 Network I/O",
                "使用率が低かった日数"
            ],
            "id": "Qch7DwouX1",
            "name": "使用率の低いAmazon EC2 Instances"
        },
    ]
}

metadata についてはチェック項目によって異なっています。

ここで得られた id を用いてチェックの詳細を表示してみます。表示するには以下のコマンドを打ちます。

$ aws support describe-trusted-advisor-check-result --language ja --check-id Qch7DwouX1

出力結果は以下になります。

{
    "result": {
        "checkId": "Qch7DwouX1",
        "status": "warning",
        "flaggedResources": [
            {
                "status": "warning",
                "resourceId": "見せられないリソースID",
                "region": "見せられないリージョン",
                "isSuppressed": false,
                "metadata": [
                    "ap-northeast-1b",
                    "見せられないID",
                    "見せられないインスタンス名",
                    "見せられないインスタンスタイプ",
                    "$90.72",
                    "2.2%  0.23MB",
                    "2.2%  0.23MB",
                    "2.2%  0.23MB",
                    "2.2%  0.23MB",
                    "2.1%  0.23MB",
                    "2.1%  0.23MB",
                    "2.2%  0.23MB",
                    "2.1%  0.23MB",
                    "2.1%  0.23MB",
                    "2.2%  0.23MB",
                    "2.2%  0.23MB",
                    "2.2%  0.22MB",
                    "2.2%  0.23MB",
                    "2.1%  0.23MB",
                    "2.2%",
                    "0.23MB",
                    "14 日"
                ]
            },
        ],
        "timestamp": "2017-11-28T02:44:46Z",
        "resourcesSummary": {
            "resourcesFlagged": "見せられない数字",
            "resourcesProcessed": "見せられない数字",
            "resourcesSuppressed": "見せられない数字",
            "resourcesIgnored": "見せられない数字"
        },
        "categorySpecificSummary": {
            "costOptimizing": {
                "estimatedMonthlySavings": "見せられない数字",
                "estimatedPercentMonthlySavings": "見せられない数字"
            }
        }
    }
}

このように様々なチェック結果をコマンドで取得することができます。さらに言えばコマンドで取得できるということは API があるということなので自分でプログラムを組んで Slack などと連携することでチェックの速報を流したり自動化することができます。夢が広がりますね。

CloudWatch での監視

CloudWatch でもメトリクスの監視ができ、しきい値を超えたら Slack への通知や、Lambda 関数のキックなどができるので定期的に監視するのであれば利用したいところです。

気をつけたいこととしては東京リージョンの CloudWatch では追加できず、バージニアリージョンだとできるということです。探し回らないように注意しましょう。

06.png

07.png

あと取れるメトリクスは各アラート基準に該当する要素の個数なので、詳しい情報が得られないことに気をつけてください。キックする Lambda で API を利用して詳細を得るのが良いと思います。

以下はSlackで通知した時の例です。

08.png

まとめ

以上かんたんですが Trusted Advisor についてまとめてみました。コストやセキュリティに関する診断を自動的に行なってくれているのでインフラ周りの見直しで重宝しそうです。

そして月並ではありますが、改めてこういうところにも API を提供している AWS ってすごいなと思いました。

続きを読む

CentOS 7でAmazon EBSのボリュームを拡張する

Amazon EC2インスタンスとしてCentOS 7を選んだ場合にAmazon Elastic Block Store(EBS)のボリュームを拡張する方法です。

本稿では以下の手順に従ってその方法を説明します。

  1. Amazon EBSボリュームを拡張する
  2. ブロックデバイス(/dev/xvda1)のサイズを拡張する

確認した動作環境

  • OS(EC2インスタンス): CentOS Linux release 7.3.1611 (Core)

前提条件

ファイルシステムは CentOS 7標準の「XFS」 であることを前提とします。

ファイルシステムの種類は以下のコマンドを入力することで確認することができます。

$ df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/xvda1     xfs        16G   16G   0G  99% /
...
...
...

dfコマンド

df コマンドは、システムのディスク領域の使用量についての詳しいレポートを表示します。

18.4. ブロックデバイスとファイルシステムの表示 – Red Hat Customer Portal

-Tはファイルシステムの種類を表示するオプションです。

Amazon EBSボリュームを拡張する

Amazon EBSボリュームの料金体系を確認する

Amazon EBSボリュームを拡張した場合、どれくらいの費用がかかるのかを事前に確認しておきましょう。

リージョンが「アジアパシフィック(東京)」の場合(2017年11月27日現在)

ボリューム 料金(ドル) 料金(円) 単位
Amazon EBS 汎用 SSD (gp2) ボリューム $0.12 12.6円(105円/ドルとした場合) 1 か月にプロビジョニングされたストレージ 1 GB あたり

「Amazon EBS 汎用 SSD (gp2) ボリューム」の場合、I/Oはボリュームの料金に含まれているため、 プロビジョニングした各ストレージのGBに対してのみ課金されます。

最新の料金体系は「料金 – Amazon Elastic Block Store(ブロックストレージ)|AWS」から確認することができます。

「Amazon EC2 コンソール」からEBSのボリュームサイズを変更する

コンソールからEBSのボリュームサイズを変更する手順は
コンソールからの EBS ボリュームの変更 – Amazon Elastic Compute Cloud」から確認することができます。

これまでの手順でEBSのボリュームサイズを変更することができますが、続いてブロックデバイスのサイズを拡張する必要があります。

ブロックデバイス(/dev/xvda1)のサイズを拡張する

ブロックデバイスのサイズを確認する

以下のコマンドを入力してブロックデバイスのサイズを確認しましょう。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  32G  0 disk
└─xvda1 202:1    0  16G  0 part /

上記の例ではxvda1のサイズが16Gであることが分かります。

lsblkコマンド

lsblk コマンドを使用すると、利用可能なブロックデバイスの一覧を表示できます。

一覧表示された各ブロックデバイスについて lsblk コマンドが表示するのは次のとおりです。デバイス名 (NAME)、メジャーおよびマイナーデバイス番号 (MAJ:MIN)、リムーバブルデバイスかどうか (RM)、そのサイズ (SIZE)、読み取り専用デバイスかどうか (RO)、そのタイプ (TYPE)、デバイスのマウント先 (MOUNTPOINT) です。

18.4. ブロックデバイスとファイルシステムの表示 – Red Hat Customer Portal

ブロックデバイスを拡張する

それでは以下のコマンドを入力してブロックデバイスを拡張しましょう。

$ sudo xfs_growfs /dev/xvda1

xfs_growfsコマンド

xfs_growfs コマンドを使用すると、マウント中の XFS ファイルシステムを拡大することができます。

-D size オプションでファイルシステムを指定の size (ファイルシステムのブロック数) まで大きくします。 -D size オプションを指定しない場合、xfs_growfs はデバイスで対応できる最大サイズにファイルシステムを拡大します。

6.4. XFS ファイルシステムのサイズの拡大 – Red Hat Customer Portal

もう一度以下のコマンドを入力してブロックデバイスのサイズを確認しましょう。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  32G  0 disk
└─xvda1 202:1    0  32G  0 part /

xvda1のサイズが16Gから32GBに変更されたことが分かります。


クリエイティブ・コモンズ・ライセンス
この 作品 は クリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供されています。

続きを読む