20190820のAWSに関する記事は13件です。

Amazon Connectで簡単なヘルプデスクを作ってみる

この記事を書いた背景

Amazon Connectが東京リージョンに展開されていることは、
知っていたのですが、なかなか触る機会がなく、先日ひょんなことから触ることがありました。

Amazon Connect とは

All-in-Oneのコンタクトセンターサービス。

All-in-Oneというのは次がポイント

  • コンタクトセンターに利用するアプリケーションおよびサブスクリプション費用
  • サーバ設置箇所(大抵、DCなど)
  • 電話回線費用(PBXも含む)

2019-08-20_230214.png

Amazon Connectの無料枠

https://aws.amazon.com/jp/connect/pricing/

Amazon Connect を 12 か月間無料で開始していただけます。
最初の Amazon Connect コンタクトセンターをデプロイすると、
毎月 90 分間の Amazon Connect サービスの使用、
AWS リージョンの所在する国からの直通ダイヤル (DID) 番号、
毎月 30 分間の受信 DID 通話、毎月 30 分間の AWS リージョンが所在する国への発信通話が得られます。

ただ、Direct Dial(050,03)とToll Free(0800,0120)と2パターンあるので、
間違えて後者のToll Freeを選択すると、無料枠の恩恵が受けられないので注意です。

個人的に最近 コンタクトセンター という言葉が、
従来のコールセンターで、インバウンドのクレーム処理やアウトバウンドの営業といったことから、
顧客の体験価値(所謂、UX)を高める目的で言葉を使い分けることを知った初心者です。
というところで、一般にコンタクトセンターはどういったサービス提供されているか、
5分程度検索結果を見てみました。

従来のコンタクトセンター

https://www.heartful.cc/service/

1,000円/1回 ※1フロー

https://www.central-eye.co.jp/price/

1,500円 月額/30回まで

http://www.zerostart-callctsys.com/developer_seller/avaya.html

1,781,600円(参考価格)~

コンタクトセンターは一度構築すると色々と変更が(コスト的に)難しそうですね。

実際に作ってみた

Amazon Connect立ち上げ

画面の入力で必要な管理者情報、インバウンド/アウトバウンドの有無などを設定(5分程度)

2019-08-07_115812.png

エンジニアの手順に見かけるビルド作業中、コピー中なのでコーヒータイムを、というのも不要でした。

2019-08-07_115910.png

さくっとフロー作成

2019-08-07_161505.png

ユーザ側の気持ちで、社内の問い合わせで機器(パソコン)関連で問い合わせるんだったらこんな感じかなと、
いったところで、オブジェクトを置いて、発話して欲しいことを書いたりしました。

発話に関して、Amazon Pollyを利用しているため、
日本語の場合、 Mizuki(女性の声)/ Takumi(男性の声)の2択ですが、
今回はMizukiに全て発話させました。

他にも、 DTMF(Dual-Tone Multi-Frequency)、所謂電話のダイヤルキーで"ピッ、ポッ、パッ"と押して、
条件分岐を設定するところです。

作成してみての感想

こんなに簡単に作成できるのか、と驚きました。
システム保守運用業務のエンジニアでもあるので、
やはりこういったものを活用するとしたら、
システムアラートの通知ですね。

Lambdaとも組み合わせられるので、
他のサービス連携であったりすることは十分できるのですが、
注意点が2つほどあるので、今後の自身の見返すように含めて記載します。

  • Connect-Lambda連携許可設定はAWS CLIからのみ ※2019年8月上旬時点

Lambda関数作成時にトリガーとなるイベント(S3 PUT、CloudWatch Eventなど)を選択するかと思いますが、
2019年8月上旬時点ではConnectは存在しないため、選択できません。
AWS CLIからのみ権限付与が必要です。

>aws lambda add-permission --function-name function:<Lambda_function_name> ^
More?  --statement-id 1 --principal connect.amazonaws.com  ^
More?  --action lambda:InvokeFunction ^
More?  --source-account <AWS Account ID> ^
More?  --source-arn arn:aws:connect:ap-northeast-1:<AWS Account ID> :instance/<Instance ID>
{"Sid":"1","Effect":"Allow","Principal":{"Service":"connect.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:ap-northeast-1:<AWS Account ID>:function:<Lambda_function_name>","Condition":{"StringEquals":{"AWS:SourceAccount":"<AWS Account ID>"},"ArnLike":{"AWS:SourceArn":"arn:aws:connect:ap-northeast-1:<AWS Account ID>:instance/<Instance ID>"}}}

  • Connect内で呼び出すLambda関数は8秒以内 ※2019年8月上旬時点

レスポンスがあまり遅いLambda関数は組み込めません。
組み込んだとしても、エラーとなりフローが終わってしまいます。
そのため、重たい処理(特定のEC2を検索して、処理を行わせる)を組み込みたい場合は、
SQSなどに一旦突っ込んで、本処理用Lambdaを呼び出すといったことの設計にする必要があります。
元々が電話のインバウンドなので、通話中のユーザが増えれば、
AWS内部の回線トラフィックも混雑して他のサービスに影響が出る可能性もあるので仕方がないと思います。

コールセンター初心者の自分でも簡単に書けるということは、
以前からコールセンターの業務で運用設計を行っていた人が作成すると、
ものすごいフローが、今までの投資コストと比較すると低コストで実現できると思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

JavaScriptでAmazon S3にファイルをアップロード

概要

Web ブラウザーから実行する JavaScript で、AJAX 通信で Amazon S3 の Bucket にできるだけセキュアに画像ファイルをアップロードできるようにしてみます。
取り扱い可能な画像ファイルは png、jpeg、gif を想定しています。
作業は、次の順で進めます。

  1. アップロード先となる S3 Bucket の作成
  2. S3 に PutObject だけが可能なポリシーを作成
  3. STS が使用するロールの作成
  4. アップロードのみ可能なIAMユーザーを作成
  5. Lambda 関数を作成
  6. Lambda が使用するロールにポリシーをアタッチ
  7. API Gateway を作成
  8. クライアントプログラムの作成

アップロード先となる S3 Bucket の作成

アップロード先となる Bucket を作成します。
ここでは、 images という名前で Bucket を作成します。

アップロード先のフォルダーを uploads としたいので、uploads フォルダーの作成もしましょう。

images Bucket は画像ファイルは Web ページからアクセスされるようにしたいので、S3 のプロパティから Static website hosting を有効にします。
インデックスドキュメントは、ファイルが存在しなくても index.html を指定しておけば Static website hosting が有効になります。

最終的に異なるドメインから S3 の画像ファイルを参照することになるので、CORS の設定が必要です。
CORS というのは、ドメインをまたいで JavaScript を実行可能にする仕組みです。読み方は“コルス”と発音することが多いようです。
簡単に説明すると、ドメインをまたいで JavaScript の実行を許すと他のページから自分の作った JavaScript を使っていたずらされたり、XSS などの脆弱性になりかねないので、JavaScript を実行可能なドメインを限定することで意図しない使われ方がされないようにするものと思っていただければと思います。

images Bucket の S3 のアクセス制限から CORS の設定を行いましょう。

ここでは、公開する Web アプリケーションのサーバーのホスト名を myserver.com とします。
ファイルの作成と更新を許可するため、HTTPメソッドはPUTとPOSTを許可します。

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>https://myserver.com</AllowedOrigin>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

S3 に PutObject (リソースの作成・置換)だけが可能なポリシーを作成

最終的にファイルをアップロード可能な URL を公開するので、アップロード以外のことができてほしくはありません。
万が一アップロード可能な URL を実行可能な機能がなんらかの方法によって乗っ取られたとしても PutObject しかできなければファイルを盗み取られるようなことはありません。
そのため、S3:PutObject のみ可能なポリシーを作成します。
このポリシーは後述の Lambda 関数から使用します。

ここでは UploadablePolicy という名前にしました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::images/uploads/*"
        }
    ]
}

STS が使用するロールの作成

STS(Security Token Service) は一時的な認証情報を取得するために使用します。一時的な認証情報は S3 にアップロードするための URL を署名するために使用します。

ここでは、RoleForTemporary という名前にしました。
”ポリシーをアタッチします”ボタンを押して、UploadablePolicy をアタッチしてください。

アップロードのみ可能な IAM ユーザーを作成

特定の権限しかもたないユーザーのアクセスキーと、シークレットアクセスキーを使用したいので IAM ユーザーを作成します。
既存の IAM ユーザーのアクセスキーとシークレットアクセスキーを使用してもいいのですが、人に割り当てられていたものを使用する場合、その人が異動したり退職した場合など割り当てを変更する必要がでてきて煩わしいので、人に割り当てられていない IAM ユーザーにすることをオススメします。

ここでは、 upload_user というユーザー名の IAM ユーザーを作成しました。
この IAM ユーザーはプログラムによるアクセスしかしないので、アクセスの種類を”プログラムによるアクセス”にチェックを入れて作成しました。
アクセス許可の設定では、“既存のポリシーを直接アタッチ”から、UploadablePolicy をアタッチしてください。
タグの設定は不要です。

Lambda 関数を作成

Lambda 関数の作成で、“一から作成”で各設定を以下のようにします。

  • 名前・・・uploadFunc
  • ランタイム・・・Node.js 6.10
  • ロール・・・カスタムロールの作成

ロールのドロップダウンで、“カスタムロールの作成”を選択すると、ロールの概要を入力するページが開きます。
ロール名を入力してください。
ここでは、RoleForUploadFunc にしました。

続いて“関数の作成”ボタンを押して関数コードにプログラムを書いていきます。
uploadFunc フォルダー以下のプログラムを編集します。index.js は最初から用意されているファイルです。uploadFunc フォルダーに lib.js というファイルも作りましょう。
後述する API Gateway でリクエストパラメーターをリクエストパラメーターとして受け取らず、JSON で受け取るように設定するのですが、そうしている理由は、JSON で受け取ると、Lambda 関数単体でのテストがしやすいためです。

uploadFunc/index.js

'use strict';

var lib    = require('./lib');
var aws    = require("aws-sdk");
var sts    = new lib.sts("RoleForTemporary");
var bucket = "images";

module.exports.handler = function(event, context, cb) {
    if (!event.file) {
        return lib.respond(cb, 400, 'Parameter "file" is missing.');
    } else if (!event.type) {
        return lib.respond(cb, 400, 'Parameter "type" is missing.');
    }

    //STSでS3に書き込み権限のあるロールを要求
    sts.assumeRole(function (err, data) {
        if (err) return lib.respond(cb, err);
        else {
            var credencials = data.Credentials;
            var s3 = new aws.S3({
                "accessKeyId" : credencials.AccessKeyId,
                "secretAccessKey" : credencials.SecretAccessKey,
                "sessionToken" : credencials.SessionToken
            });
            var s3_params = {Bucket: bucket, Key: "uploads/" + event.file, ContentType: event.type}; // アップロードするURLに対し署名
            var signed_url = s3.getSignedUrl('putObject', s3_params);
            var response = {"signedurl":signed_url};

            return lib.respond(cb, null, response);
        }
    });
};

uploadFunc/lib.js

accessKeyID の値は、IAM ユーザー upload_user のアクセスキーをセットしてください。ここでは、ABCDEFGHIJKLMNOPQRST であったとして進めます。
secretAccessKey の値は、IAM ユーザー upload_user のシークレットアクセスキーをセットしてください。ここでは、abcdefghijklmnopqrstuvwxyz0123456789ABCD であったとして進めます。
RoleArn のアカウント ID は AWS のアカウント ID です。ここでは、123456789012 であったとして進めます。

'use strict';

var aws = require("aws-sdk");

function sts_(roleName) {
    this.stsobj = new aws.STS({
        "accessKeyId": "ABCDEFGHIJKLMNOPQRST",
        "secretAccessKey": "abcdefghijklmnopqrstuvwxyz0123456789ABCD"
    });
    this.param = {
        "RoleArn": "arn:aws:iam::123456789012:role/" + roleName,
        "RoleSessionName": "session_" + roleName
    };
}
sts_.prototype.assumeRole = function(cb) {
    return this.stsobj.assumeRole(this.param, cb);
};

module.exports = {
    "respond" : function(cb, err, body) {
        if (err) {
            if (typeof err == 'object') {
                if (!err.status) err.status = '400';
                else if (typeof err.status == 'number') err.status = err.status + '';
            } else if ((err + '').match(/^[0-9]{3}$/)) {
                err = {
                    "status" : err,
                    "message" : body
                };
            }
            err = JSON.stringify(err);
        }
        return cb(err, body);
    },
    "sts": sts_
};

Lambda が使用するロールにポリシーをアタッチ

IAM で、RoleForUploadFunc ポリシーを選択して、”ポリシーをアタッチします”ボタンを押して、UploadablePolicy をアタッチしてください。

API Gateway を作成

API Gateway を作成すると、EC2 で Apache や nginx を用意しなくても Web API を公開することができます。

Lambda のコンソールから、左側の”トリガーの追加”にある”API Gateway”を追加してください。

“トリガーの設定”の API のドロップダウンから“新規 API の作成”を選択してください。
そうすると、セキュリティというドロップダウンが現れるので、“オープン”を選択します。

”▼追加の設定”を押して、“バイナリメディアタイプ”を設定します。
追加するバイナリメディアタイプは以下の3つです。

  • image/png
  • image/gif
  • image/jpeg

設定しおえたら右下にある“追加”ボタンを押してください。

Lambda のコンソールで、API Gateway に uploadFunc-API というハイパーリンクが現れるので、それを押してください。
そうすると API Gateway のコンソールが表示されます。

リソース欄に /uploadFunc が表示されるのでそれを選択します。
そして、その上にある“アクション▼”と書かれたドロップダウンを押してください。そして“メソッドの作成”を押してください。

そうすると ANY の下にドロップダウンが表示されるので、そこで GET を選択してください。セットアップのページが開きます。

セットアップ

/uploadFunc - GET - セットアップと表示されたページが表示されるので以下のように設定します。

  • 統合タイプ・・・ Lambda 関数
  • Lambda プロキシ統合の使用・・・チェックしない
  • Lambda リージョン・・・ap-northeast-1 (もちろん、別のリージョンをご利用であれば変更してください)
  • Lamda 関数・・・uploadFunc
  • デフォルトタイムアウトの使用・・・チェックする

以上を入力したら”保存“ボタンを押してください。メソッドの実行設定のページが開きます。

メソッドの実行設定

メソッドの実行に関する設定を行います。メソッドリクエストと、統合リクエストの設定を変更します。メソッドレスポンスと統合レスポンスの設定は変更しません。

メソッドリクエスト

API Gateway が受け取るリクエストパラメーターを登録します。

URLクエリ文字列パラメータに、file と type を追加してください。それぞれ必須とキャッシュのチェックボックスはチェックしなくてかまいません。

統合リクエスト

公開した Web API が受け取ったリクエストパラメーターを JSON データに変換します。

マッピングテンプレートのリクエスト本文のパススルーから“テンプレートが定義されていない場合(推奨)”を選択し、Content-Type に application/json を追加します。
テンプレートの JSON を以下の通りにしてください。

{
    "file" : "$input.params('file')",
    "type" : "$input.params('type')"
}

CORS 設定

最終的に異なるドメインから STS のトークンを発行することになるので、CORS の設定が必要です。
STS のトークンは S3 に公開する URL を署名してセキュアにするために使用します。

リソース欄の /uploadFunc を選択します。
そして、その上にある“アクション▼”と書かれたドロップダウンを押してください。そして“CORSの有効化”を押してください。

CORS の有効化ページで、以下のように設定してください。

  • uploadFunc-API API のゲートウェイレスポンス・・・DEFAULT 4XX:チェックなし、DEFAULT 4XX:チェックなし
  • メソッド・・・GETとOPTIONSをチェック(OPTIONSはチェックを外せない)
  • Access-Control-Allow-Headers・・・'*'
  • Access-Control-Allow-Origin*・・・'*'

続いて、”CORS を有効にして既存の CORS ヘッダーを置換”を押してください。

メソッドのデプロイ

API Gateway で API を公開する作業を行います。この作業の後、Lambda のコンソールで関数を編集してもやりなおす必要はありません。

リソース欄の /uploadFunc を選択します。
そして、その上にある“アクション▼”と書かれたドロップダウンを押してください。そして“APIのデプロイ”を押してください。

API のデプロイと書かれた小さなウィンドウが表示されるので、デプロイされるステージから default を選択して、”デプロイ”ボタンを押してください。

クライアントプログラムの作成

以下のような HTML と JavaScirpt (jQuery) でファイルをアップロードします。
プログラム中の URL https://1234567890.execute-api.ap-northeast-1.amazonaws.com/default/uploadFunc は、Lambda のコンソールに表示されたものを使用してください。1234567890 の部分はランダムな英数字で構成されます。

アップロードの仕組みは以下の通りです。

  1. https://1234567890.execute-api.ap-northeast-1.amazonaws.com/default/uploadFunc?〜 でアップロード先の S3 の URL を取得する。
  2. 取得した URL に対して input type="file" のファイルを POST する。

1で取得するアップロード先の S3 の URL は 15 分有効な URL です。それ以降に使用すると、タイムアウトのエラーが発生します。本ページ中に 15 と入力するところがなかったのでお気づきかもしれませんが、デフォルトが 15 分だからです。
変更したければ、Lambda 関数の uploadFunc/index.js のコメント“// アップロードするURLに対し署名”のある行のパラメーターを変更してください。詳しくは AWS の資料をご覧ください。

<form action="." method="post" class="upload form">
  <div class="columns">
    <div class="column is-12">
      <div class="file has-name">
        <label class="file-label">
          <input class="file-input" type="file" name="resume">
          <div class="file-cta">
            <span class="file-icon"><i class="fa fa-cloud-upload" aria-hidden="true"></i></span>
            <span class="file-label">ファイルを選択...</span>
          </div>
          <span class="file-name"><i class="fa fa-question" aria-hidden="true"></i></span>
        </label>
      </div>
    </div>
  </div>
  <div class="columns">
    <div class="column is-12">
      <input type="button" class="upload button" name="upload-button" value="アップロード">
    </div>
  </div>

  <div class="columns">
    <div class="column is-12 uploaded"></div>
  </div>
</form>
<script>
  $(function () {
    $(".upload.button").on('click', function () {
      var error = null;
      var orig_file = $('.file-input').prop('files')[0];
      var up_file = "bar/foo.png";

      $.ajax({
        url: 'https://1234567890.execute-api.ap-northeast-1.amazonaws.com/default/uploadFunc?file=' + up_file + '&type=' + orig_file.type,
        type: 'GET'
      }).then(function (data) {
        return $.ajax({
          url: data.signedurl,
          type: 'PUT',
          data: orig_file,
          contentType: orig_file.type,
          processData: false
        });
      }).then(function (data) {
        console.log("Upload success");

        $(".uploaded").append($("<img />").attr("src", "http://images.s3-website-ap-northeast-1.amazonaws.com/uploads/" + up_file));
      }).fail(function (data) {
        error = data.message || data.statusText || data.errorText;
      })
        .always(function (jqXHR, textStatus) {
          if (error) {
            console.log("Error: " + error);
          }
        });

      // false を返してデフォルトの動作をキャンセル
      return false;
    });
  });
</script>

課題

本ページで紹介したファイルのアップロードだと、ファイルの格納場所を指定しているので、存在するファイルを上書きできてしまいます。
本ページで紹介したファイルのアップロードを実装するアプリによっては、他人が作成したファイルを上書きできてしまったりするので場合によっては脆弱性になりかねません。
実装するアプリによっては他人のアップロードしたファイルを上書きできないようにする仕組みを別途組み込んだり、する工夫が必要になると思います。
そういった点に注意してご利用ください。

参考にしたページ

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSソリューションアーキテクト資格勉強のメリットとその方法

記事概要

  • AWS認定ソリューションアーキテクト アソシエイト資格を勉強するメリットの紹介
  • 実際に合格するまでにおこなった勉強法の紹介

対象読者

  • これから、AWS認定ソリューションアーキテクト アソシエイトを受験しようと考えている方
  • 資格試験の勉強なんて本当に意味あるの?と懐疑的な方
  • どうやったらソリューションアーキテクト アソシエイトって合格できるの?と疑問をお持ちの方

勉強するメリット

ソリューションアーキテクトの勉強する最大のメリットは、AWSの体系的な知識が効率的に学べる点だと考えています。
私自身がそうでしたが、「AWSは使ったことがあるものの、EC2・RDS・S3・Route53くらいしか分からない」という方は多いのではないかと思います。
いざ勉強しようと思っても、書店に並んでいるものはクラウドデザインパターンだったり、実例集のようなものが多く、AWS全体の俯瞰図を得るにはやや物足りないという印象です。
そんな人には、是非ソリューションアーキテクト資格の勉強をおすすめしたいです。

ソリューションアーキテクトでは、「設計者」という立場からシステム全体の構成を問う問題が多く出るので、必然的に幅広いサービスの概要と特徴をおさえることになります。なので、仮に試験を受けなかったとしても、現在、各出版社から出ている試験対策の教科書をとりあえず一周読むだけでも効率よく多くのサービスを知ることができます。
正直、私も最初は受験しようと思って勉強したわけではありませんでした。不合格だったとしても労力に見合った知識は身についたので満足していたと思います。

で、実際に勉強してみて実務で役に立つの?という疑問は当然あるかと思うので、そちらに回答すると、合格する前の時点でもかなり役立ちました。
私は、会社のプロジェクトで開発リーダーを務めていることもあり、システムの設計にも関わるタイミングがありました。その際、EC2 + RDSという構成のWeb APIサーバをAPI Gateway + Lambda + DynamoDBのサーバーレスアーキテクチャへ移行する提案をおこなったのですが、サーバーレス以降へのメリットやAPI Gateway + Lambda + DynamoDBのスケーラビリティやDynamoDBの冗長性についてはかなり説得力のある説明ができたと感じました。

それ以外でも、社内で散逸している開発部ごとのAWSアカウントの管理方法に関する助言や、ACMを使ったSSL証明書の管理、ELB + EC2の組み合わせにおけるAutoScalingに関する提案など、社内AWSコンサルタントとして認知度が上がったという実感があります。
ソリューションアーキテクト試験の勉強で万遍なく知識を入れておくと、サービス選定の「WHY」に曇りなく答えることができるので、自分の関わるプロジェクトでもサーバー構成に対する不安が軽減します。

勉強法

使用した教材

これだけです。合格者の体験記を読んでいると、ホワイトペーパーを読んでいる方も多く見かけましたが、特に必要性は感じませんでした。

学習手順

  • 教科書を1回通読。よくわからないサービスがあってもあまり気にせず1週間くらいで読み通す。章末のテストもちゃんと解く。
  • 教科書購入者は、インプレス社が提供している模擬試験のPDFが手に入るので、解く。
  • 上で、間違えた問題は解説を読む。正解を選ぶ上でのキーワードは、エディタでもノートでも良いのできちんとまとめておく。
  • 教科書を再度通読。2周目にも関わらず親しみを覚えないサービスは、きちんと暗記用にまとめておく。
  • AWS公式の模擬試験(有料。税込み(8%)2160円)を受験する。
  • 上で、スコアレポートに各分野の得点率が出るので、それを元にして教科書を復習する。
  • 試験前日に、インプレス社の模擬試験を解いて、自信をつける。

こんな学習法で見事合格しました。

さいごに

勉強するか迷っている人は、勉強して損はないので是非勉強してみてください。
勉強してみて、腕試ししたいという気持ちになったら、受験してみたらいいかと思います。

偉そうに、書きましたがAWSのサービスは幅広く、まだまだ触ったことのないサービスだらけです。
ソリューションアーキテクト アソシエイト試験の合格を機に、様々な知見を得られるようにトライしていきたいです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【RDS for Oracle】18cが利用可能に

RDS for Oracleで18cが利用可能

  • RDSでOracle Database 18cが利用可能になりました。
  • 東京リージョンでも使えます。
  • 18cは従来でいう12.2.0.2に相当します。

18cからのリリースサイクル

説明
従来 数年ごとのメジャーリリースサイクル
(例)11g R2 -> 12c R1 -> 12c R2
18cから 年次リリース
2018年にリリースされたので18c。
2019年にリリースされたら19c

12.2からパッチも変更

  • RU(Release Update)とRUR(Release Update Revisions)の2つに変わりました
パッチの種類 説明
RU 四半期ごとの修正パッチ。
従来でいうPSU相当。
RUR RUに対するセキュリティおよびリグレッションの修正が含まれる。
RURを適用することでRUを最新のセキュリティレベルに保つ。
個別パッチ リクエストによりつくられる
  • RUもRURも従来の PSU/BP と同様 1月、4月、7月、10月にリリース
  • RURは、対応するRUを適用している状態でのみ適用可能。
    • 既存のRUに対しRURを適用。
    • 既存のRUに対し最新のRUを適用。

バージョンの読み方

スクリーンショット 2019-08-20 22.17.54.png

RUとRUR

スクリーンショット 2019-08-20 22.18.03.png

スクリーンショット 2019-08-20 22.19.50.png

スクリーンショット 2019-08-20 22.20.01.png

参考

Oracle Database 18c テクノロジーシリーズ 1 「DB Core と Oracle Multitenant の進化」~ DB Core ~

ORACLE RELEASE MODEL, RELEASE UPDATES (RU), AND RELEASE UPDATE REVISIONS (RUR)

Amazon RDS now supports Oracle Database 18c

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

JAWS-UG IoT専門支部 「AWS IoTシリーズのシンカ(進化/深化/真価)」に参加してきたことのメモ

はじめに

こちらのイベントに参加してきたのでそれについてまとめます。(久しぶりに自分の仕事と関係ありそうな内容を聞きに行ったなあ。。。)

JAWS-UG(AWS Users Group – Japan)とはその名前の通りAWSの日本ユーザーグループのようです。AWSは様々なクラウドサービスを展開していますが、今回は「AWS IoT」についての勉強会でした。

イベント詳細・タイムテーブルなどはイベントページを参照してもらうことにして、以下から各セッションについてのメモ書きを残します。内容が多かったので、箇条書きメモっぽくなって記事らしい内容にはなりませんでした。。。

AWS IoT サービスこの1年の進化 (AWSJ 亀田さん)

以下に紹介されたサービスについて書きます。といっても詳細についてはメモしきれてません。

AWS IoT core

AWS IoTを使う用途は主に2つ

  • データ収集
  • リモート制御

AWS IoT以外にもAmazonにはAmazon Kinesisというサービスもサポートしている

  • AWS IoT
    • HTTP, MQTT, WebSocketをサポート
    • 双方向制御ができる
    • クライアント証明書をサポート
    • 値段高め
  • Amazon Kinesis
    • HTTPのみをサポート
    • 専用ライブラリが必要
    • データストリーム

AWS IoT Device Management

AWS IoT coreでできることは各デバイスに証明書を与えることであるが、このサービスでは複数のデバイスをまとめて制御可能。AWS IoT Testerでテスト可能。

AWS IoT Analytics

IoTデータの収集・前処理・拡張・保存・分析・可視化を可能にするサービス。ストレージに保存したデータに対して分析が可能であり、リアルタイムでの分析は不可。

AWS IoT SiteWise

工場。農場からの大量のデータをストレージに貯めるためのサービス。収集したデータをアセット単位・プロセス単位で処理が可能。

Amazon Free RTOS

マイクロコントローラ向きのIoT operating systemを提供するサービス。

AWS IoT Greengrass

Edgeデバイスのためのサービス。Greengrass Coreをインストールしたデバイスをゲートウェイのソフトウェアから操作することでクラウドベースでの管理が可能になる。

まとめ

それぞれにリンクを貼ったので詳細はそれぞれのドキュメントを参照してください。一口にAWS IoTといっても様々なサービスがあったことを今回初めて知りました。個人的に気になったのはFreeRTOSですね。

AWS IoTサービスの理解の深化と真価 (AWSJ 市川さん)

ここで紹介されたサービスは2つです。

  • AWS Things Qraph
  • AWS IoT Events

AWS Things Graph

NodeREDのようなGUI操作で複数デバイスとサービスの接続を記述することで、視覚的にワークフローを制御することができる。デバイスとサービスは、モデルと呼ばれる再利用可能な構築済みコンポーネントとして表され、プロトコルやインターフェイス等の低レベルの詳細は表示されず、モデルを統合して複雑なワークフローを作成することも簡単に行える(サイトの説明抜粋)。モデルの定義はGraphQLによる記述が必要。

AWS IoT Events

AWS IoT core・AWS IoT Analyticsからのデータを継続的に監視するステートフルなイベントの管理が可能。ユースケースとして、複数のデータを監視して複雑なイベントの管理をしたい場面に使える。また、大量なデータに含まれるノイズに対する処理(何回通知したら警告みたいな処理)が可能になり、サーバに通知する無駄な通信を減らすことができる。注意点は以下の2点

  • オートセーブの機能がないので定期的にPublishすることが必須
  • 一定期間データが来ないと保存されていたデータとモデルが削除される

まとめ

両者とも新しく提供されたサービス(2019年時点)なので、ぜひリンク先でチェックしておくと良いかもしれません。AWS IoT Events・AWS Things GraphともにGUIベースになっているので直感的な記述ができそうだなと感じました。

IoTのつくり方~おさえておくと捗るモロモロ (JAWS UG IoT専門支部運営 青木さん)

IoTシステムの基本構成から各要素についての解説をメモ。

IoTデバイス

ここで重要になるのは電源。

データの特性

  1. 定期的に収集されるデータ
    • 連続して投げられるもの
  2. 離散的に発生するデータ
    • あるイベントにのみ発生する

エリアネットワークのプロトコル問題

例えばWifiとXBeeはチャンネルがかぶっているので同時に通信することが難しい。

ゲートウェイ

データのどこでタイムスタンプを付与するか。

  • センサ
    • 実際にデータを取得した時間が取得できる
    • 時計同期の実装が必要
  • ゲートウェイ
    • 一括管理が可能
    • 誤差あり

ゲートウェイにどこまでのスペックをもたせるかを考える。あえてゲートウェイを採用しないケースもある

広域通信網

LPWA・3Gなど様々な方式がある

IoTサーバ

コストと安定した運用のために使えるマネジメントサービスは積極的に取り入れる。やれるところからマイクロシステムの疎結合にする。

さいごに

完全にメモ書きな内容になりました。なにか補足・指摘ありましたら編集リクエストください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2 インスタンスでのカーネルパニックの生成を、リモートでトリガーする(EC2:SendDiagnosticInterrupt API)

参考記事

新着 – カーネルパニックをトリガーし、応答しない EC2 インスタンスを診断

Sending a Diagnostic Interrupt (Advanced Users Only)

EC2:SendDiagnosticInterrupt API

NITRO世代のEC2インスタンスで稼働中のOSに対し、ハードウェアNMI(マスク不可割り込み)を発生させて、OSの強制再起動が可能になりました。

  • NMI 割り込みを受信したときのOSの挙動は、システムの設定に依存します。

    • 通常はカーネルパニックの状態に入ります。
  • カーネルパニックの挙動

    • OSの設定に依存します。
    • クラッシュダンプデータファイルの生成がトリガーされる。
    • システムが再起動されたりなど。
  • ダンプを調べるときのルツール

    • WinDbg (Windows)
    • crash (Linux)

難しいことは考えずやってみた

割り込みを受信したときの OS の挙動を設定しておく

Amazon Linux 2 で、kdump と kexec をインストールおよび設定する。

sudo yum install kexec-tools

/etc/default/grub を編集する。クラッシュカーネル用に予約するメモリの量(crashkernel=150M)を割り当てる。
参考:kernel doc

/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=150M console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"

grub の設定を再構築する。
参考【 grub2-mkconfig/grub-mkconfig 】コマンド――GRUB 2の起動メニューを生成する

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

/etc/sysctl.confにkernel.unknown_nmi_panic=1を追加する。
1に設定すると、カーネルが未定義のNMIを検出した場合にパニックが発生します。
参考4.2.4 カーネル・パニックを制御するパラメータ

/etc/sysctl.conf
kernel.unknown_nmi_panic=1

kdump が正常に開始されていることを確認する。

systemctl status kdump.service

● kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2019-08-19 05:52:41 UTC; 1min 8s ago
  Process: 3192 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
 Main PID: 3192 (code=exited, status=0/SUCCESS)

Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: -rw-r--r--   1 root     root    ...2
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: -rw-r--r--   1 root     root    ...0
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: drwxr-xr-x   2 root     root    ...r
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: lrwxrwxrwx   1 root     root    ...k
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: lrwxrwxrwx   1 root     root    ...n
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: ================================...=
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: *** Creating initramfs image fil...*
Aug 19 05:52:41 ip-10-0-0-51.ap-northeast-1.compute.internal kdumpctl[3192]: kexec: loaded kdump kernel
Aug 19 05:52:41 ip-10-0-0-51.ap-northeast-1.compute.internal kdumpctl[3192]: Starting kdump: [OK]
Aug 19 05:52:41 ip-10-0-0-51.ap-northeast-1.compute.internal systemd[1]: Started Crash recovery kernel arming.
Hint: Some lines were ellipsized, use -l to show in full.

API をトリガーする

aws ec2 send-diagnostic-interrupt --region us-east-1 --instance-id <value>

なお、サポートしていないインスタンスタイプの場合は↓のようなエラーが表示されたのでt2.micro→t3a.mediumにした。

An error occurred (UnsupportedOperation) when calling the SendDiagnosticInterrupt operation: This instance type does not support diagnostic interrupts.

インスタンスが再起動され、インスタンスに再接続すると、/var/crash にクラッシュダンプがあるはず。

ls -la /var/crash
total 0

kdump.conf は path /var/crash になっているんだが。。。

クラッシュダンプの内容を分析する

crash ユーティリティとデバッグシンボルをインストールしておく必要があるる。

/var/crashなかったので、とりあえずメモで。

sudo yum install crash
sudo debuginfo-install kernel
sudo crash /usr/lib/debug/lib/modules/4.14.128-112.105.amzn2.x86_64/vmlinux 

      KERNEL: /usr/lib/debug/lib/modules/4.14.123-111.109.amzn2.x86_64/vmlinux
    DUMPFILE: /proc/kcore
        CPUS: 2
        DATE: Tue Aug 20 06:49:26 2019
      UPTIME: 00:10:32
LOAD AVERAGE: 0.08, 0.02, 0.01
       TASKS: 107
    NODENAME: ip-10-0-0-51.ap-northeast-1.compute.internal
     RELEASE: 4.14.123-111.109.amzn2.x86_64
     VERSION: #1 SMP Mon Jun 10 19:37:57 UTC 2019
     MACHINE: x86_64  (2199 Mhz)
      MEMORY: 4 GB
         PID: 2829
     COMMAND: "crash"
        TASK: ffff888131238000  [THREAD_INFO: ffff888131238000]
         CPU: 0
       STATE: TASK_RUNNING (ACTIVE)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

続・インバウンドポートを全閉したAWSのサーバに接続する方法 〜P2P編〜

はじめに

この記事はremote.itについて私が書いた以下の内容の続編です。是非事前にご覧ください。

これは魔法か?! インバウンドポートを全閉したAWSのサーバに接続する方法

なぜP2Pか?

先の記事の最後に「実は、今回紹介した接続方法は、remote.itがクラウドにホストしているサーバ経由で接続しています。」と書きました。この記事に対して多くの好意的な反響をいただいた反面、remote.itがホストしているサーバを介して接続されることによる不安やリスクについてのコメントも寄せられました。
そこで今回は接続がremote.itのサーバを経由しない、P2P接続の方法をご紹介します。

remote.itのクライアントアプリケーションのインストール

今回は一番最新のMacOS用ベータアプリを使います。
まず、下記のremote.itのドキュメントサイトから、ソフトウェアをダウンロードします。

Using the Desktop App (Beta, macOS only)

ダウンロードしたdmgファイルを展開し、アプリケーションをインストールして実行します。
スクリーンショット 2019-07-29 21.23.54.png

アプリケーションを実行するとサインイン画面が表示されるので、remote.itアカウントでサインインします。

スクリーンショット 2019-07-29 21.25.22.png

P2P接続の実行

アプリケーションにサインインすると、アカウントに対して登録されているデバイスのリスト(Webポータルと同じもの)が表示されます。
前回登録した「test-ubuntu18-web」がありますね。
スクリーンショット 2019-07-29 21.26.05.png

デバイス名の右側のアイコンをクリックすると、登録されているサービス(アプリケーション)が展開されます。
スクリーンショット 2019-07-29 21.26.17.png

接続したいサービスをクリックします。接続に成功するとアイコンが水色のドーナツ型のものに変わります。
また、このサービスへの接続がlocalhostのポート33002で開始したことが分かります。
スクリーンショット 2019-07-30 9.03.42.png

もう一つのサービスにも接続しました。こちらはlocalhostのポート33000で開始しました。
スクリーンショット 2019-07-30 9.03.53.png

実際にローカルホスト(127.0.0.1)でLISTENしているポートを確認してみます。

$ netstat -an |grep 127.0.0.1 |grep LISTEN

確かに3300033002でそれぞれ待ち受けているようです。
スクリーンショット 2019-07-30 9.06.10.png

アプリケーションからP2P接続を使ってアクセスする

それでは実際にアプリケーションから接続します。
今回、localhost:33000はubuntuサーバのsshサービスでしたので、ターミナルからsshコマンドでlocalhost:33000に対して接続してみます。
スクリーンショット 2019-07-30 9.07.37.png

無事接続できました。よく見ると接続元が127.0.0.1になっていることが分かります。
スクリーンショット 2019-07-30 9.07.53.png

同様に、localhost:33002はubuntuサーバのWebサービスですので、ブラウザからlocalhost:33002に対してアクセスするとubuntuサーバのWebコンテンツ(今回はapacheのデフォルトページ)が表示されました。
スクリーンショット 2019-08-20 15.21.01.png

まとめ

接続元側にもremote.itのクライアントを用意することで、自分のアカウントに登録されている接続先デバイスに対して簡単にP2P接続を行うことができます。
今回はAWS上のHTTPとSSHの例を紹介しましたが、一般的なTCP/IPの作法に則ったアプリ(IPアドレスとポート番号で会話できるアプリ)であれば、プロトコルやターゲットのロケーション(回線の種別)は問いません。VPNのようにインターネットをプライベートなネットワークとして使える一方で、VPNのようにインターネットに対して入り口を用意する必要がありません。

前回の記事ではさも魔法かのように書きましたが、実際はもちろんカラクリがありremote.itはいわゆるNAT越えを実現するサービスです。そのため、双方のネットワーク環境によっては今回紹介したP2P接続が成功しない可能性があることにご注意ください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS ソリューションアーキテクト プロフェッショナル (SAP-C01 2019-06-24版)受験記録

1. はじめに

2019年8月にAWS 認定ソリューションアーキテクト プロフェッショナルを受けて合格しました。

8割以上取れたかなという感覚でしたが、スコア782で結構危なかったです。
2019年6月に受験して一度落ちてから今回までにどんな学習方法をしたのか記録します。参考になれば幸いです。
なお、試験問題に繋がる内容は記載はしないよう気を付けています。

※2019年6月に受験時の記録
前回:AWS ソリューションアーキテクト プロフェッショナル SAP-C01 不合格 受験記録

2. SAP-C01試験 2019-06-24について

今回受験したSAP-C01自体は2019月2月に改定された新試験になります。今回の試験予約時にアクティブ日を見たところ「2019-06-24」となっていたので、その時点で内容が更新された可能性が高いと思います。

AWS Certificateのよくある質問に、「新しい製品、サービス、機能は一般公開された (GA) 6 か月後に、認定試験に反映されるようになります。」と明記されているので、昨年暮のre:Invent辺りで出てきたサービスや機能はがっつり試験対象になったと想定して進めています。

3. 学習方法

学習期間:約1ヶ月(+前回の2週間)
学習時間:約50時間(+前回の30時間)

前回は試験対策気味になってしまったので、基本に立ち返ってサービスの理解という意識で学習方法を見直しました。

現状もプロフェッショナル向けの良い日本語コンテンツは無いので8~9割は英語コンテンツがメインです。
しかし、Google翻訳という強い味方をフル活用して今回は学習しました。

使ったもの

前回あまり活用しませんでしたが「よくある質問」を読み込むのはかなりオススメです。
出来る・出来ない・制限事項が明記されているので、問題文のシナリオを評価するのに役立ちます。
実際試験中「このパターンは出来そうで出来ないんだよな」と自信持って答えられるケースが増えていました。

また「ホワイトペーパー」を読み込むのも強くオススメします。
上記にお気に入りを挙げていますが、実際には20近くのホワイトペーパー資料に目を通しました。
ホワイトペーパーのPDFは英語の資料が多いので、google翻訳にPDFを投げ込んで翻訳しながら、
逆に翻訳で分かりにくいケースも多いので、英語版も並べて比較しながら読んだ感じです。

上記、udemyの有料模試も非常に参考になります。解説が非常に丁寧なので読み込むことをお勧めします。
全問題3周使って、解答を覚え始めてしまっていたのもありますが終盤は90%平均程度正解出来ていました。

4. 試験当日のこと

  • 安定の歌舞伎座CBTSで受講

猛暑日でしたが、室内はちょっと寒かったので、長袖のシャツで良かったです。

今回は全て終わった段階で残り45分。フラグ付き37問。残り5分までじっくりと見直ししました。
最後まで理解出来ない問題が10問ぐらい残りましたが、前回は見直しまで終わった段階でもフラグが20問近く残っていたので、まぁ大丈夫だろ!って感じで終了を押せました。

5. 試験の感想

2回目を受けた感想としては、基本方針は前回の感想と変わっていません。
全てのサービスの用途は一言程度で最低限把握しましょう
(上記【2019年】AWS全サービスまとめ記事シリーズを全てざっと読む。)

試験のポイントなど

前回で記述したところは除きます。

  • Well-Architectedフレームワークすべて重要ですが、特に「信頼性」と「コスト最適化」は理解する
    • 全て実現可能なシナリオの場合はWell-Architectedフレームワークに当てはめて考える
  • 基本的なサービス理解に加え、エンタープライズ用途や大規模利用、既に多くのリソースを持つハイブリッド構成を想定した場合どうするかを考慮する
  • VPCやEC2、各種ストレージなど基本的なリソースについてはre:Invent辺りで出てきた機能も含めて、特に深く理解を推奨。
    • TransitGatewayやDirectConnectGatewayの登場でVPCの構築パターンはかなり変わりました。(自分の時は出ませんでしたが)Global Acceleratorも含めて様々な構築パターンが検討出来ます。
    • 必ずしも新機能が選択肢にあるとは限りませんので、新サービスが出てきた背景も併せて確認するといい
  • 問題文にて問われていることをよく読む
    • 実際見直し段階で問われていることの違いに気づいて2問程度直しました。解答は全てが有効な答えのことが多いので、細部の記載によく注意してどれが最適か選んだ方がいいです。
    • 時間が無いので、ハマると焦ります。その場合は暫定で答えておいてフラグ付けて後から確認でもいいかも知れません。
  • アマゾン ウェブ サービスに移行するの内容および「6つの一般的なアプリケーション移行ステージ」を理解する
  • 別リージョンに「素早く」デプロイする手段を色々把握しておく。
    • バックアップや移行+RTO、RPOは絶対問われると思います。

特に重要なサービス
 Organizations、Systems Manager、Service Catalog、Storage Gateway、Server Migration Service、Database Migration Service、Key Management Service
自分の場合はこれらが多い印象だったので参考程度に。

DevOpsも取って5冠と行きたいところですが、かなり疲弊したのでしばらくはFE風花雪月の消化に勤しみます。
これから望む人は頑張ってください!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS ソリューションアーキテクト プロフェッショナル SAP-C01 合格 受験記録

1. はじめに

2019年8月にAWS 認定ソリューションアーキテクト プロフェッショナルを受けて合格しました。

8割以上取れたかなという感覚でしたが、スコア782で結構危なかったです。
2019年6月に受験して一度落ちてから今回までにどんな学習方法をしたのか記録します。参考になれば幸いです。
なお、試験問題に繋がる内容は記載はしないよう気を付けています。

※2019年6月に受験時の記録
前回:AWS ソリューションアーキテクト プロフェッショナル SAP-C01 不合格 受験記録

2. SAP-C01試験 2019-06-24版について

今回受験したSAP-C01自体は2019月2月に改定された新試験になります。今回の試験予約時にアクティブ日を見たところ「2019-06-24」となっていたので、その時点で内容が更新された可能性が高いと思います。

AWS Certificateのよくある質問に、「新しい製品、サービス、機能は一般公開された (GA) 6 か月後に、認定試験に反映されるようになります。」と明記されているので、昨年暮のre:Invent辺りで出てきたサービスや機能はがっつり試験対象になったと想定して進めています。

3. 学習方法

学習期間:約1ヶ月(+前回の2週間)
学習時間:約50時間(+前回の30時間)

前回は試験対策気味になってしまったので、基本に立ち返ってサービスの理解という意識で学習方法を見直しました。

現状もプロフェッショナル向けの良い日本語コンテンツは無いので8~9割は英語コンテンツがメインです。
しかし、Google翻訳という強い味方をフル活用して今回は学習しました。

使ったもの

前回あまり活用しませんでしたが「よくある質問」を読み込むのはかなりオススメです。
出来る・出来ない・制限事項が明記されているので、問題文のシナリオを評価するのに役立ちます。
実際試験中「このパターンは出来そうで出来ないんだよな」と自信持って答えられるケースが増えていました。

また「ホワイトペーパー」を読み込むのも強くオススメします。
上記にお気に入りを挙げていますが、実際には20近くのホワイトペーパー資料に目を通しました。
ホワイトペーパーのPDFは英語の資料が多いので、google翻訳にPDFを投げ込んで翻訳しながら、
逆に翻訳で分かりにくいケースも多いので、英語版も並べて比較しながら読んだ感じです。

上記、udemyの有料模試も非常に参考になります。解説が非常に丁寧なので読み込むことをお勧めします。
全問題3周使って、解答を覚え始めてしまっていたのもありますが終盤は90%平均程度正解出来ていました。

4. 試験当日のこと

  • 安定の歌舞伎座CBTSで受講

猛暑日でしたが、室内はちょっと寒かったので、長袖のシャツで良かったです。

今回は全て終わった段階で残り45分。フラグ付き37問。残り5分までじっくりと見直ししました。
最後まで理解出来ない問題が10問ぐらい残りましたが、前回は見直しまで終わった段階でもフラグが20問近く残っていたので、まぁ大丈夫だろ!って感じで終了を押せました。

5. 試験の感想

基本方針は前回の感想同様、移行、複数アカウント運用、最適なアーキテクチャ、RTO・RPO、DR辺りの複雑なシナリオが問われますが、改めて見返してみるとプロフェッショナルの「試験ガイド」はよく出来ています。記載の分野の通りの出題範囲(当たり前ですが)なので、自分は試験ガイドをよく読みながら分野毎に対象っぽいサービスを列挙しました。併せて試験ガイドに記載のホワイトペーパーも目を通しながら+有用そうなタイトルのホワイトペーパーに目星付けると良いです。

参考:試験ガイド分野

分野 1: 組織の複雑さに対応する設計
分野 2: 新しいソリューションの設計
分野 3: 移行の計画
分野 4: コスト管理
分野 5: 既存のソリューションの継続的な改善

また、全てのサービスの用途は最低限一言程度で把握しましょう
(上記【2019年】AWS全サービスまとめ記事シリーズを全てざっと読む。)

試験や学習のポイントなど

前回で記述したところは除きます。

  • Well-Architectedフレームワークすべて重要ですが、特に「信頼性」と「コスト最適化」は理解する
    • 全て実現可能なシナリオの場合はWell-Architectedフレームワークに当てはめて考える
  • 基本的なサービス理解に加え、エンタープライズ用途や大規模利用、既に多くのリソースを持つハイブリッド構成を想定した場合どうするかを考慮する
  • VPCやEC2、各種ストレージなど基本的なリソースについてはre:Invent辺りで出てきた機能も含めて、特に深く理解を推奨。
    • TransitGatewayやDirectConnectGatewayの登場でVPCの構築パターンはかなり変わりました。(自分の時は出ませんでしたが)Global Acceleratorも含めて様々な構築パターンが検討出来ます。
    • 必ずしも新機能が選択肢にあるとは限りませんので、新サービスが出てきた背景も併せて確認するといい
  • 問題文にて問われていることをよく読む
    • 実際見直し段階で問われていることの違いに気づいて2問程度直しました。解答は全てが有効な答えのことが多いので、細部の記載によく注意してどれが最適か選んだ方がいいです。
    • 時間が無いので、ハマると焦ります。その場合は暫定で答えておいてフラグ付けて後から確認でもいいかも知れません。
  • アマゾン ウェブ サービスに移行するの内容および「6つの一般的なアプリケーション移行ステージ」を理解する
  • 別リージョンに「素早く」デプロイする手段を色々把握しておく。
    • バックアップや移行+RTO、RPOは絶対問われると思います。

特に重要なサービス

 Organizations、Systems Manager、Service Catalog、Storage Gateway、Server Migration Service、Database Migration Service、Key Management Service
自分の場合はこれらが多い印象だったので参考程度に。

DevOpsも取って5冠と行きたいところですが、かなり疲弊したのでしばらくはFE風花雪月の消化に勤しみます。
これから望む人は頑張ってください!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

インスタンスストアの自動マウント方法(忘備)

インスタンスストアの自動マウント方法(忘備)

インスタンスストアはホストに依存する。
再起動(実行ホストが変わる)とデバイス自体が別物になるので毎々ファイルシステム作成とマウントが必要になるので/etc/rc.localにファイルシステム作成とマウントコマンド書いておく

環境

  • os: CentOS Linux release 7.6.1810 (Core)
  • ami-id: ami-045f38c93733dd48d
  • instance-type: t2.micro

環境確認

os
# more /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)
ami-id,instance-typ
# ec2metadata --ami-id --instance-type
ami-045f38c93733dd48d
x1e.4xlarge
disk
# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   50G  0 disk
mqxvda1 202:1    0   50G  0 part /
xvdb    202:16   0  447G  0 disk #インスタンスストア
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       50G  1.5G   49G   3% / #EBSのみマウントされている
devtmpfs        241G     0  241G   0% /dev
tmpfs           241G     0  241G   0% /dev/shm
tmpfs           241G   25M  241G   1% /run
tmpfs           241G     0  241G   0% /sys/fs/cgroup
tmpfs            49G     0   49G   0% /run/user/0
tmpfs            49G     0   49G   0% /run/user/1000
# ls -la /dev/xv*
brw-rw----. 1 root disk 202,  0 Aug 20 04:57 /dev/xvda
brw-rw----. 1 root disk 202,  1 Aug 20 04:57 /dev/xvda1
brw-rw----. 1 root disk 202, 16 Aug 20 04:56 /dev/xvdb #インスタンスストア
# more /etc/fstab

# /etc/fstab
# Created by anaconda on Mon Jan 28 20:51:49 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=f41e390f-835b-4223-a9bb-9b45984ddf8d /                       xfs     defaults        0 0
/dev/xvdb       /mnt    auto    defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig       0       2
#既に記載があるがファイルシステムが作成されていないのでマウントされない

作業

mkdir,mount
# mkfs -t ext4 /dev/xvdb
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
29302784 inodes, 117184940 blocks
5859247 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2264924160
3577 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
# mount -a
# # df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       50G  1.5G   49G   3% /
devtmpfs        241G     0  241G   0% /dev
tmpfs           241G     0  241G   0% /dev/shm
tmpfs           241G   25M  241G   1% /run
tmpfs           241G     0  241G   0% /sys/fs/cgroup
tmpfs            49G     0   49G   0% /run/user/0
tmpfs            49G     0   49G   0% /run/user/1000
/dev/xvdb       440G   73M  418G   1% /mnt

起動時の自動マウント

/etc/rc.local
# echo "mkfs -t ext4 /dev/xvdb" >> /etc/rc.local
# more /etc/rc.local
#!/bin/bash
# THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES
#
# It is highly advisable to create own systemd services or udev rules
# to run scripts during boot instead of using this file.
#
# In contrast to previous versions due to parallel execution during boot
# this script will NOT be run after all other services.
#
# Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure
# that this script will be executed during boot.

touch /var/lock/subsys/local
mkfs -t ext4 /dev/xvdb
mount -a
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

「知っ得ハンズオンはじめてのAmazon Personalize」に参加してきたのでまとめる

Amazon Personalizeハンズオン

知っ得ハンズオンはじめてのAmazon Personalize に参加して、
初めてAmazon Personalizeを触ったので、まとめてみました。

2019-08-19_181356.png

座学パート

AWSのミッション

「全ての開発者に機械学習を」

機械学習とAI

蓄積された データ をもとに一定の推察を得るアルゴリズムの育成
※投資フェーズ

→ データサイエンティスト
   プライバシーの造詣
   全社のデータ戦略
   最新アルゴリズムの追求

ユーザに付加価値として推察を提供する ビジネスロジック
※回収フェーズ

→ フロントエンドエンジニア
   プライバシーの造詣
   Webサービスへの組み込み
   UXのエキスパート

Amazon Personalizeとは

・レコメンデーションサービス(個人化推薦)
・機械学習経験不要
・Amazon.comと同様のテクノロジー(DeepLearning)

補足事項

  • Personalizeで読み込ませるデータに、時系列の項目は必須
  • アクティビティストリームは、動的にアイテムが変わる場合に有効。  静的なアイテムを取り扱う場合は、有効にする必要はない。
  • 再計算されるタイミングは、アンドキュメント(公式に文書化されていない)。 一方で、インジェクションを行うと再計算が実行される。 つまり1週間で一回再実行することで計算をさせることも運用上組み込んでもいい。
  • 基本的にはAutoMLを選択肢、データを読み込ませて自動でアルゴリズム選択を任せるのがいい。
  • Amazon Forecastという制度の高い時系列予測サービスが現在プレビュー版で提供されている

ハンズオンパート

AWSから提供された資料

  • ハンズオンの作業手順が記載されたドキュメント
  • ハンズオンで利用するテストCSVデータ(ユーザID、映画のID、時系列)

ハンズオン概要

S3

  • 前述のCSVデータを格納するS3バケットを作成(※)

  • 作成したS3バケットにバケットポリシーを適用

{
    "Version": "2012-10-17",
    "Id": "PersonalizeS3BucketAccessPolicy",
    "Statement": [
        {
            "Sid": "PersonalizeS3BucketAccessPolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "personalize.amazonaws.com"
            },
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::<S3-bucket-name>",
                "arn:aws:s3:::<S3-bucket-name>/*"
            ]
        }
    ]
}

※既にあるS3バケットを利用してもいいですが、
 上記のS3バケットポリシーでPersonalizeからアクセスする権限を付与するので、
 ハンズオン後にS3ごと削除することを踏まえると、新規で作成しました

Amazon Personalize

  • Dataset Groupを作成 2019-08-19_190000.png
  • user-item interaction dataを作成 2019-08-19_190132.png
    • PersonalizeからS3を読み込むIAM Roleを作成 2019-08-19_190243.png
  • S3から先程アップロードしたファイルの読み込み開始 2019-08-19_190342.png
  • solution作成 2019-08-19_191738.png
  • campaign作成 2019-08-19_202048.png

このcampaignが、推論モデルのエンドポイントという形で提供されたら、あとはテスト

  • Test Campaign results

そのまま画面から推論モデルの検証
2019-08-19_203220.png
- AWS CLI

別途、LightSailでAmazonLinuxのインスタンスを作成し、
AWS configureでプロファイル設定後、AWS CLIで推論モデルを実行検証
2019-08-19_203329.png

画面、AWS CLIから取得された結果が同じなので、無事にハンズオン完了しました。

受講してみて

ここまで簡単にモデルができるというのは、個人的には参加してよかったです。

今まで機械学習というと、どうしてもデータサイエンティストのように大量のデータを前にして、
どういったモデルを適用して、検証をするか設計するというところでいつも詰まっていました。
特に前述した、強調フィルタリングというのはシンプルなロジックでいて、
なかなか厄介でレコメンデーションのモデル作成に手を焼きました。(過去形)

また、ノンプログラミングで実装できるというところで、
エンジニアを抱えていないけど、機械学習を取り組める膨大なデータを持っている事業を行っている方も、
このPersonalizeを活用できますね。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS ソリューションアーキテクト試験問題【第2弾】

AWS ソリューションアーキテクト試験問題 皆でAWSを勉強しましょう。【2回目】

まずは100問作りました。お時間のある時に試験対策として活用してみて下さい。

ぜひ御社AWSエンジニア様向けで共有いただき、ご活用ください。

合わせまして、弊社ではAWS案件のご用意がありますのでもしAWSエンジニア様がいらっしゃいましたらぜひお引き合わせください。

AWS認定ソリューションアーキテクト・アソシエイトにどれくらいで受かるか?

受かるまで試験問題を解くのみです。

STRA株式会社が問題集を用意します!

AWSの技術者とクライアント様にAWSの良さを広めましょう

http://stra.co.jp/ses/2019/07/28/4057/
http://stra.co.jp/ses/2019/07/29/4059/
http://stra.co.jp/ses/2019/07/29/4061/
http://stra.co.jp/ses/2019/07/29/4063/
http://stra.co.jp/ses/2019/07/30/4065/
http://stra.co.jp/ses/2019/07/30/4073/
http://stra.co.jp/ses/2019/07/30/4075/
http://stra.co.jp/ses/2019/07/31/4077/
http://stra.co.jp/ses/2019/07/31/4079/
http://stra.co.jp/ses/2019/07/31/4081/
http://stra.co.jp/ses/2019/08/01/4083/
http://stra.co.jp/ses/2019/08/01/4085/
http://stra.co.jp/ses/2019/08/01/4087/
http://stra.co.jp/ses/2019/08/02/4089/
http://stra.co.jp/ses/2019/08/02/4091/
http://stra.co.jp/ses/2019/08/02/4093/
http://stra.co.jp/ses/2019/08/03/4095/
http://stra.co.jp/ses/2019/08/02/4097/
http://stra.co.jp/ses/2019/08/02/4099/
http://stra.co.jp/ses/2019/08/02/4101/
http://stra.co.jp/ses/2019/08/02/4103/
http://stra.co.jp/ses/2019/08/02/4105/
http://stra.co.jp/ses/2019/08/03/4107/
http://stra.co.jp/ses/2019/08/03/4109/
http://stra.co.jp/ses/2019/08/03/4111/
http://stra.co.jp/ses/2019/08/03/4113/
http://stra.co.jp/ses/2019/08/03/4115/
http://stra.co.jp/ses/2019/08/03/4117/
http://stra.co.jp/ses/2019/08/04/4119/
http://stra.co.jp/ses/2019/08/04/4121/
http://stra.co.jp/ses/2019/08/04/4123/
http://stra.co.jp/ses/2019/08/04/4125/
http://stra.co.jp/ses/2019/08/04/4127/
http://stra.co.jp/ses/2019/08/04/4129/
http://stra.co.jp/ses/2019/08/05/4131/
http://stra.co.jp/ses/2019/08/05/4133/
http://stra.co.jp/ses/2019/08/05/4135/
http://stra.co.jp/ses/2019/08/05/4137/
http://stra.co.jp/ses/2019/08/05/4139/
http://stra.co.jp/ses/2019/08/05/4141/
http://stra.co.jp/ses/2019/08/06/4143/
http://stra.co.jp/ses/2019/08/06/4145/
http://stra.co.jp/ses/2019/08/06/4147/
http://stra.co.jp/ses/2019/08/06/4149/
http://stra.co.jp/ses/2019/08/06/4151/
http://stra.co.jp/ses/2019/08/06/4153/
http://stra.co.jp/ses/2019/08/07/4155/
http://stra.co.jp/ses/2019/08/07/4157/
http://stra.co.jp/ses/2019/08/07/4159/
http://stra.co.jp/ses/2019/08/07/4161/
http://stra.co.jp/ses/2019/08/07/4163/
http://stra.co.jp/ses/2019/08/07/4165/
http://stra.co.jp/ses/2019/08/08/4167/
http://stra.co.jp/ses/2019/08/08/4169/
http://stra.co.jp/ses/2019/08/08/4171/
http://stra.co.jp/ses/2019/08/08/4173/
http://stra.co.jp/ses/2019/08/08/4175/
http://stra.co.jp/ses/2019/08/08/4177/
http://stra.co.jp/ses/2019/08/09/4179/
http://stra.co.jp/ses/2019/08/09/4181/
http://stra.co.jp/ses/2019/08/09/4183/
http://stra.co.jp/ses/2019/08/09/4185/
http://stra.co.jp/ses/2019/08/09/4187/
http://stra.co.jp/ses/2019/08/09/4189/
http://stra.co.jp/ses/2019/08/10/4191/
http://stra.co.jp/ses/2019/08/10/4193/
http://stra.co.jp/ses/2019/08/10/4195/
http://stra.co.jp/ses/2019/08/10/4197/
http://stra.co.jp/ses/2019/08/10/4199/
http://stra.co.jp/ses/2019/08/10/4201/
http://stra.co.jp/ses/2019/08/11/4204/
http://stra.co.jp/ses/2019/08/11/4206/
http://stra.co.jp/ses/2019/08/11/4208/
http://stra.co.jp/ses/2019/08/11/4210/
http://stra.co.jp/ses/2019/08/11/4212/
http://stra.co.jp/ses/2019/08/11/4214/
http://stra.co.jp/ses/2019/08/12/4216/
http://stra.co.jp/ses/2019/08/12/4218/
http://stra.co.jp/ses/2019/08/12/4220/
http://stra.co.jp/ses/2019/08/12/4222/
http://stra.co.jp/ses/2019/08/12/4224/
http://stra.co.jp/ses/2019/08/12/4226/
http://stra.co.jp/ses/2019/08/13/4228/
http://stra.co.jp/ses/2019/08/13/4230/
http://stra.co.jp/ses/2019/08/13/4232/
http://stra.co.jp/ses/2019/08/13/4234/
http://stra.co.jp/ses/2019/08/13/4236/
http://stra.co.jp/ses/2019/08/13/4238/
http://stra.co.jp/ses/2019/08/14/4240/
http://stra.co.jp/ses/2019/08/14/4242/
http://stra.co.jp/ses/2019/08/14/4244/
http://stra.co.jp/ses/2019/08/14/4246/
http://stra.co.jp/ses/2019/08/14/4248/
http://stra.co.jp/ses/2019/08/14/4250/
http://stra.co.jp/ses/2019/08/15/4252/
http://stra.co.jp/ses/2019/08/15/4254/
http://stra.co.jp/ses/2019/08/15/4256/
http://stra.co.jp/ses/2019/08/15/4258/
http://stra.co.jp/ses/2019/08/15/4260/
http://stra.co.jp/ses/2019/08/15/4262/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLIをインストールする

はじめに

PC買い替えによりAWS CLIの再インストールが必要となったため、手順をメモしておく。

インストール手順

pipインストール

  • 以下コマンドを実行してパッケージをインストール。
# curl -O https://bootstrap.pypa.io/get-pip.py
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1733k  100 1733k    0     0  1152k      0  0:00:01  0:00:01 --:--:-- 1153k
#
# python get-pip.py
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Collecting pip
/tmp/tmpmFVf6o/pip.zip/pip/_vendor/urllib3/util/ssl_.py:365: SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. You can upgrade to a newer version of Python to solve this. For more information, see 

・・・(省略)・・・

Collecting wheel
  Downloading https://files.pythonhosted.org/packages/00/83/b4a77d044e78ad1a45610eb88f745be2fd2c6d658f9798a15e384b7d57c9/wheel-0.33.6-py2.py3-none-any.whl
Installing collected packages: pip, wheel
Successfully installed pip-19.2.2 wheel-0.33.6
/tmp/tmpmFVf6o/pip.zip/pip/_vendor/urllib3/util/ssl_.py:149: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
#
  • インストール確認。
# pip --version
pip 19.2.2 from /usr/lib/python2.7/site-packages/pip (python 2.7)
#

AWS CLIインストール

  • pipを使用してAWS CLIをインストール。
# pip install awscli
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Collecting awscli

・・・(省略)・・・

  Downloading https://files.pythonhosted.org/packages/73/fb/00a976f728d0d1fecfe898238ce23f502a721c0ac0ecfedb80e0d88c64e9/six-1.12.0-py2.py3-none-any.whl
Building wheels for collected packages: PyYAML
  Building wheel for PyYAML (setup.py) ... done
  Created wheel for PyYAML: filename=PyYAML-5.1.2-cp27-cp27mu-linux_x86_64.whl size=44875 sha256=e84f3e8cd7774e2a183283ac18aa20e290d8ab155d1c83d32fb4971bb6d376d0
  Stored in directory: /root/.cache/pip/wheels/d9/45/dd/65f0b38450c47cf7e5312883deb97d065e030c5cca0a365030
Successfully built PyYAML
Installing collected packages: colorama, pyasn1, rsa, docutils, PyYAML, futures, urllib3, six, python-dateutil, jmespath, botocore, s3transfer, awscli
Successfully installed PyYAML-5.1.2 awscli-1.16.220 botocore-1.12.210 colorama-0.3.9 docutils-0.14 futures-3.3.0 jmespath-0.9.4 pyasn1-0.4.6 python-dateutil-2.8.0 rsa-3.4.2 s3transfer-0.2.1 six-1.12.0 urllib3-1.25.3
#
  • インストール確認。
# aws --version
aws-cli/1.16.220 Python/2.7.5 Linux/3.10.0-229.el7.x86_64 botocore/1.12.210
#

AWS CLI設定

  • aws configureコマンドでシークレットキー諸々登録して終了。

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む