Quantcast
Channel: 技術 –サーバーワークスエンジニアブログ
Viewing all 1210 articles
Browse latest View live

IAM Access Analyzer が S3 アクセスポイントポリシーに対応しました!

$
0
0

はじめに

こんにちは、技術1課の山中です。
ずっと最近は家に引きこもっていますが、家のネットが貧弱でとても辛いです。
そんな中、同僚から有線にしなよとアドバイスをもらいました。
面倒だし頑なに拒否していたのですが、一昨日くらいから試しに有線に変えてみて、すこぶる調子がよくなりました。
有線、よいです。

今回は IAM Access Analyzer のアップデートです。
IAM Access Analyzer はこれまでも S3 バケットについてはサポートしていたのですが、バケットに適用されているバケットポリシーと ACL についてのみの検出しかできませんでした。
今回のアップデートで新たに S3 アクセスポイントポリシーにも対応しました!!
このアップデートで、 アクセスポイントを使用する S3 バケットへの意図しないアクセスを見つけ、アクセスを許可するアクセスポイントを特定することが簡単にできるようになります。

S3 アクセスポイントを介して共有された S3 バケットへの意図しないアクセスを検出、確認、修正する

IAM Access Analyzer とは

IAM Access Analyzer は他の AWS アカウントや外部からアクセスされる可能性があるかどうかを検出する機能で、 AWS re:Invent 2019 にて発表されました。
S3 や IAM など外部に公開できるサービスのポリシーをチェックし、一覧化してくれます。

IAM Access Analyzer とは – AWS Identity and Access Management
IAM Access Analyzerで外部アクセスポリシーを検出しよう – サーバーワークスエンジニアブログ

検出した結果は Amazon EventBridge にて通知することも可能です。

Amazon EventBridge による AWS IAM Access Analyzer のモニタリング – AWS Identity and Access Management

IAM Access Analyzer は外部からアカウント内のリソースにアクセスがあったかどうかについては関知する訳ではありません。
あくまでもポリシーを根拠に判断するだけです。

※ IAM Access Analyzer はリージョンごとに有効化する必要があります。

サポートしているリソースタイプ

2020/05/12 現在、 IAM Access Analyzer がサポートしているリソースタイプは以下です。

詳細は サポートされているリソースタイプ – AWS Identity and Access Management をご覧ください。

料金

IAM Access Analyzer は 追加料金なし でご利用いただけます。

試してみる

早速、 S3 アクセスポイントポリシーが IAM Access Analyzer でどのように検出されるのか試していきましょう!

IAM Access Analyzer の有効化

事前に IAM Access Analyzer を有効化しておきます。
有効化の手順は以下のブログを参照してください。

IAM Access Analyzerで外部アクセスポリシーを検出しよう – サーバーワークスエンジニアブログ

S3 バケットの用意

自分の AWS アカウント 111111111111の S3 バケットに S3 アクセスポイント経由で他の AWS アカウント 222222222222 からアクセスできるように S3 バケットを用意していきます。

適当な名前 yamanaka-sample-bucketで S3 バケットを作成したら、アクセスポイントへのアクセスコントロールの委任 に従いバケットポリシーを更新し S3 アクセスポイント経由でのみバケットにアクセスを許可するようにします。
アクセス権限 タブの バケットポリシー に以下を記載し保存します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "*",
            "Resource": [
                "arn:aws:s3:::yamanaka-sample-bucket",
                "arn:aws:s3:::yamanaka-sample-bucket/*"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:DataAccessPointAccount": "111111111111"
                }
            }
        }
    ]
}

続いて S3 アクセスポイントを作成します。
アクセスポイント タブにて アクセスポイントを作成 ボタンをクリックします。

アクセスポイント名 を適当に入力後、 ネットワークのアクセスタイプインターネット を選択します。

パブリックアクセスをブロック (アクセスポイント設定) では パブリックアクセスをすべてブロック のチェックを外してください。

今回はアカウント 222222222222 の IAM ユーザ daishiyamanakaに、 アクセスポイント my-access-pointを介して、 S3 バケットのオブジェクトに GETPUTのアクセス許可を付与します。
アクセスポイントポリシー に以下を貼り付け、 アクセスポイントを作成 ボタンをクリックします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::222222222222:user/daishiyamanaka"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:ap-northeast-1:111111111111:accesspoint/my-access-point/object/*"
        }
    ]
}

これで S3 バケットの用意は完了です。

試しにアカウント 222222222222にてアクセスキーを発行し、以下コマンドで画像をアップロードしてみたところ正常にアップロードされていました。

$ aws s3api put-object --bucket arn:aws:s3:ap-northeast-1:111111111111:accesspoint/my-access-point --key sample.jpeg --body sample.jpeg

IAM Access Analyzer の確認

IAM Access Analyzer を確認してみましょう!!
きちんと用意したバケットが検出されています!

対象レコードの 結果 ID をクリックして詳細を表示します。
次を介して共有 の項目にきちんとアクセスポイントが記載されていました!!!

おわりに

IAM Access Analyzer を使うと、外部からの予期せぬアクセスを未然に防ぐことができます。
無料で利用できますので是非、 AWS アカウントセットアップ時に有効化しておきましょう!!

また、この内容は 2020/5/13(水) 12:00 よりYouTube Liveで配信する「30分でわかる AWS UPDATE!」で取り上げます!
是非ご覧ください!

参考


EC2のInstance Savings PlansとスタンダードRIが値下げされました!

$
0
0

こんにちは、技術1課の小倉です。
2020/5/8にAWS News Blogにて発表があり、EC2のInstance Savings PlansとスタンダードRIが値下げされました!

EC2 Price Reduction – For EC2 Instance Saving Plans and Standard Reserved Instances

今回の値下げ対象のインスタンスタイプは、M5, C5, R5, C5n, C5d, M5a, M5n, M5ad, M5dn, R5a, R5n, R5d, R5ad, R5dn, T3, T3a, Z1d, A1で、東京リージョンでは、最大16%値下げされています(C5インスタンス)。また、すでに値下げされた料金で購入可能です。

詳細な値引きの情報は記載されておりませんが、実際の料金は公式サイトにてご確認をお願いします。

Amazon EC2 リザーブドインスタンス料金表
Savings Plans の料金

いくつか注意点があります。

  • 今回の対象は、EC2 Instance Savings PlansスタンダードRIで、オンデマンド、コンバーティブルRI、Compute Savings Plansは対象外です。
  • Windowsインスタンスは関連するライセンスにより値下げ率が異なるとのことです。

リザーブドインスタンスとSavings Plansとは

どちらも将来の利用をコミットすることでEC2などをオンデマンドよりも安く利用できる料金モデルです。リザーブドインスタンスとSavings Plansの違いについては、以下のブログにまとめられています。

Savings Plan と Reserved Instance の比較

まとめ

EC2のInstance Savings PlansとスタンダードRIが値下げされました。直近1年はEC2の利用を予定している方で、まだリザーブドインスタンスやSavings Plansを購入していない方は、購入を検討してみてはいかがでしょうか。

ちなみに私はプライベートで t2.nano のスタンダードRIを3年前払いで購入しています。その前までは1年おきに購入していたのですが、ずっと使うと思ってより割引率の高い3年を選んで購入しました。その直後に t3インスタンスが発表されましたが、 t2.nano を固定で購入しているため、インスタンスタイプを変更できず、そしてまだ1年期限が残っています。期限が切れたら t3インスタンスに変更してから購入するので、今回の割引の恩恵を受けることができます。

リザーブドインスタンスは1度購入してしまうと払い戻しができませんので、先が読めない場合は割引率は下がりますが、スタンダードRIを1年おきまたはコンバーティブルRIを購入するのがよいと思います。

また、本ブログの内容は2020/5/13(水) 12:00よりYouTube Liveで配信される「30分でわかる AWS UPDATE!」でも取り上げる予定ですので、ぜひご覧ください!
もしリアルタイムで見逃しても、アーカイブ動画から内容を確認できます。

Mac ユーザーが Amazon WorkSpaces (Windows) で仕事をするためにやったこと

$
0
0




macユーザーがAmazon WorkSpaces(Windows)を使うためにやったこと.md



Mac ユーザーが Amazon WorkSpaces (Windows) で仕事をするためにやったこと

今週から実験的にAmazon WorkSpace (Windows) を使って仕事をしています
Amazon WorkSpace (Windows) は Amazon Web Services の提供する仮想デスクトップです
仮想デスクトップは PC で稼働する OS やアプリケーションをサーバー上に集約して管理し実行する仕組みです

Amazon WorkSpaces を使う理由としてはインターネット上に仮想デスクトップ環境を作ることによるメリットがあります
① Mac のローカルストレージに業務データが入らない
② Mac のハードウェア不具合等に影響されにくい
③ 仮想デスクトップ環境のイメージバックアップ等をしておき 万一のときに速攻リストアができるようになる

結果

最高に快適に仕事できています!
生産性も上がった感じがしています

構成

初めてログインしたときの画面

Windowsですね!とてもテンションが上がりました
壁紙は後で好きな写真に変えました

使いやすくするためにやったこと

画面キャプチャツールの導入

  • Windowsの画面キャプチャツールとして定番の Winshot を入れました
    • 「JPEGで保存(アクティブウィンドウ)」のホットキーを [F9] にしました (個人の好みです)
      • Mac のショートカットキーと被らないようにしました([ctrl]+ ~ は被りやすいので注意)
      • フリーソフトですので導入は自己責任でお願いします

クリップボード管理ツールを入れました

  • クリップボード管理ツールは定番の clibor を入れました
    • [ctrl] キーを2回タップで起動
      • フリーソフトですので導入は自己責任でお願いします
    • Mac では 長らくclipy を使っています
      • こちらは[option]キーを2回タップで起動

スニペット?

スニペットも色々ありそうなものの未導入です
(Mac では DASH に大変お世話になっています)
候補は beeftextです
以前社内のWindowsユーザーに試してもらい評判がよかったので使って見る予定です
※フリーソフトですので導入は自己責任でお願いします

キーボードを Windows 用のキーボードにしました

「郷に行っては郷に従え」です
マイクロソフト社のキーボード (1400円)を買いました
Mac に Windows 用のキーボードが付いているのは異様な光景です
しかし WorkSpaces上のWindows環境で基本的にずっと仕事をする際にはこちらの方が快適です!
こちらは在宅勤務手当を使って買いました


その後「[Windows]キーが使えない!」という問題が発生し ちょっとしたことで使えるようになりました
以下の記事をご参照ください

Windows 用のキーボードを Mac で使う用のキーバインド変更

Windows 用のキーボードを Mac につけた際に
[英数]キーと[かな]キーが無くなったため Macでkarabiner-elements を使い以下のキーマッピングをしています
これをやっておくことにより WorkSpaces(Windows)側でも Mac と同じような IME 切り替えが出来て爆速です
WorkSpaces側はなんと[無変換]キーだけで IME の切り替えが全てできます
※フリーソフトですので導入は自己責任でお願いします

Visual Studio Code

もともとは Vimmer なものの せっかくなので マイクロソフト社が開発した Visual Studio Code に Vim のプラグインである VSCodeVim を入れて使うことにしました
個人的な設定を記載しておきます

{
    "editor.fontSize": 16,
    "git.autofetch": true,
    "window.zoomLevel": 1,

    // vimrc
        "vim.useSystemClipboard":true,
        "vim.cmdLineInitialColon": true,
        "vim.hlsearch": true,
        "vim.easymotion": true,
        "vim.visualstar": true,
        "vim.useCtrlKeys": true,
        "vim.insertModeKeyBindings": [
            {
                "before": ["j","j"],
                "after": ["<Esc>"]
            }
        ],
        "vim.leader": "<space>",
        "vim.normalModeKeyBindingsNonRecursive": [
            {
                "before": ["<leader>","a"],
                "after": ["v","$","h","o","0","y"]
            },
            {
                "before": ["<leader>","z"],
                "after": ["v","$","h","o","y"]
            },
            {
                "before": ["<leader>","b"],
                "after": ["v","0","y"]
            },
            {
                "before": ["<leader>","c"],
                "after": ["v","i","\"","y"]
            },
            {
                "before": ["<leader>","v"],
                "after": ["v","i","\""]
            },
            {
                "before": ["<leader>","b"],
                "after": ["v","i","'"]
            },
            {
                "before": ["<leader>","e"],
                "after": ["v","$","h","o","y"]
            },
            {
                "before": ["<leader>","s"],
                "after": [],
                "commands": [":%s###g"]
            },
            {
                "before": ["<leader>","r"],
                "after": [":","%","s","#","#","#","g"]
            },
            {
                "before": ["<leader>","w"],
                "after": [],
                "commands": [":w!"]
            },
            {
                "before": ["<leader>","d"],
                "after": [],
                "commands": [":%d"]
            },
            {
                "before": ["<leader>","y"],
                "after": ["g","g","v","G","$","y"],
            },
            {
                "before": ["<leader>", "n"],
                "after": [],
                "commands": [":nohl"]
            },
            {
                "before": ["n"],
                "after": ["n","z","z"]
            },
            {
                "before": ["N"],
                "after": ["N","z","z"]
            }
        ],
    "before": [
        "<Leader>",
        "x"
    ],
    "commands": [
        ":q!"
    ],
    "editor.fontFamily": "Noto Sans CJK JP,Noto Sans CJK JP Regular:style=Regular",
    "diffEditor.ignoreTrimWhitespace": false,
    "vim.visualModeKeyBindingsNonRecursive": [
    
    ],
    "vim.normalModeKeyBindings": [
    
    ]
}

今後

EC2 に開発環境を作成し開発作業は WorkSpaces から EC2 に繋いでやってみようかなと考えています (さらなる環境分離)
唯一欠点としてWEBカメラが使えないのでWEB会議に顔出しできていません…このあたりの恒久対処方法も探していきます(今はmacから参加)

関連記事


Amazon WorkSpaces(Windows) を Mac で使うときにWindowsロゴキーを使えるようにする方法

$
0
0




Amazon WorkSpaces(Windows) を Mac で使うときにWindowsロゴキーを使えるようにする方法.md



Amazon WorkSpaces(Windows) を Mac で使うときにWindowsロゴキーを使えるようにする方法

私は今週から Amazon WorkSpaces という 仮想デスクトップ環境を使って仕事をしています
詳細はお手数ですが以下をご参照ください

前置き

Mac には [Windows]キーがありません
その代わり Mac には [command]キーがあります

[command]キーの利用シーンとしてはコピー ( [command] + c ) や 貼り付け([command] + v) です
Windows でのコピー( [ctrl] + c ) と貼り付け( [ctrl] + v ) には [Windows] キー は使いません
[Windows]キーの利用シーンとしては スタートメニューの表示や エクスプローラーの起動 ( [Windows] + E ) や デスクトップの表示 ( [Windows] + D ) です
アプリケーションの切り替え ( [Windows] + 数字キー ) もできます
Mac の [command]キー は Windows の [ctrl]キー と同じような動作をします
Windows に存在する [Windows]キー と同等のキーは Mac にはありません

本題

Amazon WorkSpaces(Windows) を Mac で使っているときに [command]キー を押すと Windowsの [ctrl] キー と同じ動きをします
Mac には[Windows]キー の動作をするキーがないため 「[Windows]キー は使えない」ということになります
ちなみに [ctrl]キー は Windowsの [ctrl] キー と同じ動作をします
すなわち [command]キーと [ctrl]キー が同じ動作をします

「[command]キーを [Windows]キー の動作に出来ないか?」とユーザーズ・ガイドを読んでいたところ以下の方法を発見しました

  1. Mac でターミナルアプリケーションを開き以下のコマンドを実行

defaults write "com.amazon.Amazon WorkSpaces Client" remap_cmd_to_ctrl 0

  1. Amazon WorkSpacesを繋いでいる場合は切断し再接続

以上の手順で「[command]キーを [Windows]キー の動作に変更出来ました!!

以上です


【入門編】初心者が1ヶ月でソースコードを改修して、サーバーレスな社内システムのデプロイを目指す

$
0
0

はじめまして。プロセスエンジニアリング部の谷です。
最近、ルパン三世を見て、チャーリー・コーセイさんが歌うTV第1シリーズのオープ二ングテーマがカッコイイなと思ってる今日この頃です。

当社では、電話システムにAmazon Connectを使っています。
この社内Amazon Connectに電話がかかってきた際に、Slackに履歴が通知される仕組みが既にあり、Salesforceに登録があればその情報が表示されるが、ない場合には登録をしなければいけません。この電話帳への登録を楽にして、みんなが登録してくれるようにソースコードを改修していきます。
方法は後ほど。

構成図

今回の改修に必要な部分のみになります。シンプルですね。

  • お客様から社内Amazon Connectに電話がかかってくる
  • Amazon ConnectからAWS Lambdaを呼び出す
  • Salesforceの情報が保存されているデータベースに電話番号検索をかけ、振る舞いを決定する
  • 決定された振る舞い毎に、Slackに通知する ←ここを変えそう

デプロイには、Serverless FrameworkとLambdaを使います。

実践いってみよう!!!

配属されて初めての案件で、Pythonのデータ型、条件分岐も覚えているか怪しい、ライブラリやServerless Frameworkは、初めましての状態だったので、いきなり改修に入るのではなく、この案件で必要になる要素をキャッチアップするところから始めました。

準備

手元の環境は次の通りです。

  • Windows 10 Pro
  • Python: 3.7.4
  • pipenv: 2018.11.26
  • AWS CLI: 2.0.7
  • node.js: 10.20.0
  • serverless framework(sls)
    • Framework Core: 1.67.3
    • Plugin: 3.6.6
    • SDK: 2.3.0
    • Components: 2.29.1

slackclientを使ってSlackにメッセージを通知してみる

slackclient
pipを使ってslackclientをインストールします。

import slack

client = slack.WebClient(token='xxxx-1111111111-22222222222-333333333333-444444444444444444444')

response = client.chat_postMessage(
    channel='#ext-scratch',
    username='notice',
    icon_emoji=':bell:',
    text='Hello World')

Slackへ通知がきました!

Serverless Frameworkを使って、Lambda Functionをデプロイしてみる

サーバーレスのデプロイを学んでいきます。

handler.pyに’Hello World’を表示するコードを書いて実行したら、どこに出力されるのか調べてみる


Lambdaのログ出力に表示されました!

LambdaからSlackに通知してみる

import json
import os
import slack

client = slack.WebClient(token='xxxx-1111111111-22222222222-333333333333-444444444444444444444')

def slack(event,context):
    response = client.chat_postMessage(
        channel='#ext-scratch',
        username='notice",
        icon_emoji=':bell:',
        text='Hello Lambda World')

Slackへ通知がきました!

この辺りで、エラーにハマりました。

[ERROR] Runtime.ImportModuleError: Unable to import module ‘slack’: No module named ‘slack’

あれ?slackclientをインストールしたはずなのになぜ?
インストール済みのパッケージを確認してみましょう。

$ pip show slackclient
Name: slackclient
Version: 2.5.0
Summary: Slack API clients for Web API and RTM API
Home-page: https://github.com/slackapi/python-slackclient
Author: Slack Technologies, Inc.
Author-email: opensource@slack.com
License: MIT
Location: c:\users\user\.virtualenvs\hello-sbevfnvp\lib\site-packages
Requires: aiohttp
Required-by:

インストールされていますね。

Serverless Frameworkは、必要なファイルをzipファイルに圧縮してくれるので、zipフォルダにslackclientに関するファイルがあるはずです。
確認してみるとありません。

つまり、.serverless下のzipフォルダにslackclientのファイルがないため、エラーが表示されたと推測できます。
私の場合は.virtualenvsの下にあったので、読み込まれなかったみたいです。
pip show slackclientのLocationの項目をみると、.virtualenvsの下にあることがわかります。

そのため、slackclientのファイルをserverless.ymlと同じ階層に置いてあげれば、エラーが解消されます。

インストールしたはずのパッケージが使えない場合は、どこにあるか場所に注意してみてください。

対象のソースコードを改修する

いよいよ、本題です。
改修箇所にアタリをつけていきます。関係する部分がわかっていれば、スムーズに進めることができます。

Slackへの通知内容を変更するFunctionの引数に「登録のない電話番号」と「すでに登録済みの電話番号」のサンプルデータを入れてローカルで実行してみる

登録のない電話番号だった場合

すでに登録済みの電話番号だった場合

それぞれ違うメッセージがSlackに送信されます。
なんとなく、どの箇所が関係するのかアタリがついてきました。

登録のない電話番号からかかってきた際に、メッセージの末尾に絵文字が表示されるように改修する


↑こちらを表示させます。

return '{endpoint} 発信元:{src} {src_country} {name_part} :arrow_forward_gray:{act}/{actval} {ctr_link} {additional_info}{additional_info_2} {sf_register_link}'.format(
        endpoint=endpoint_emoji,
        src=src,
        src_country=src_country,
        name_part=name_part,
        act=params['action_label'],
        actval=params['action_value'],
        ctr_link=ctr_link,
        additional_info=additional_info,
        additional_info_2=additional_info_2,
        sf_register_link=sf_register_link
    )

Slackに通知されるメッセージの基本の形です。formatメソッドにより、{endpoint}や{name_part}などに、データが入ることでSlackへの通知メッセージが作られています。
そのため、上記の1行目の末尾に{sf_register_link}を書き加え、登録のない電話番号の条件式のif文に、登録画面のリンクが付いたSF登録絵文字をsf_register_linkに代入するコードを書きます。

SF登録絵文字をクリックするとSalesforceの登録画面に飛びます。

成功ですね!!!

コードのレビューなどを終えたら、

sls [--profile profile名] --stage stage名 --config serverless.stage名.yml --verbose deploy

をして本番環境にデプロイが完了です!!!

終わりに

何とか1ヵ月に間に合ってよかったです!

絵文字を追加するというちょっとしたことだったかもしれませんが、様々な社内ツールをつなげて改善していくことに、関心を持つきっかけになったと思います。
これとこれつなげたら面白いかも、楽になるかもというものを探していきたいです。

Macユーザーが本気でAmazonWorkSpaces(Windows)で仕事をしていくことに躊躇している理由

$
0
0

↓こちらの記事を投稿したものです。

数週間使っているなかで『超えられない壁』とでも言いますか、このまま継続していくことを躊躇している事象がでてきましたので、Workspacesの導入を検討されるMacユーザーのお役にたてればとの思いで内容を記載しておきます。

バンドルされているMicrosoft Office Professional が 32bit 版

これが、躊躇している最たる理由です。

業務都合で月に数回程、それなりに関数や計算式が設定された Excel ファイルを編集する必要があります。
想像に安いと思いますが、ひとつのセルの数字を書き換えるとコレを参照している別シート等で再計算が走ってくれるアレです。

手元の macOS では2秒程度の処理なのですが、WorkSpaces では再計算に60秒程度かかってしまいました。
Google 検索で出てくる一般的なパフォーマンス・チューニングはひととおり実施してみて多少は改善されたものの、残念ながら実用には耐えられる状況には至りませんでした。

  • ハードウェアグラフィックアクセラレータを無効にする
  • 使用するプロセッサ数の指定
  • WorkSpaces のスペックを PowerPro(8vCPU, 32GiBメモリ) に変更してみる

考えられる要因としては、WorkSpaces にバンドルされている Excel が 32bitアプリケーション なのが理由なんじゃないかな。と(macOS側は64bitアプリケーション)
『考えられる』と記載したのは理由がありまして、サクっと試せれば確認するのですが、WorkSpaces で自前の Office365 を利用するのってライセンス的に条件が厳しく、コストにも跳ねてしまうんです。
e.g. 2019年10月以前のボリュームライセンスを保有おり、OS も含めて BYOL する。とか

まあ、端的に言うと『やりようがない』状況ですね。
主な WorkSpaces のターゲット層にとっては、普通の利用シーンだと思っていたのですが自分の感覚がズレていたのかもしれません。

元々 WorkSpaces を使い始めた動機が『ローカルにファイルを持たないで済む』だったので、この問題はイタイところです。

Bluetoothのマイク/イヤホンの運用が面倒

サーバーワークスでは、リモートの参加者がゼロの会議が殆どありません。
その為、マイクやスピーカーの音質についての配慮が強いと感じています。

例をあげると、端末付属のマイクを利用しているメンバーが殆どいません。
端末付属のマイクってキーボードの打鍵音を多く拾ってしまうので、受け手側は非常に迷惑します。(ほんとウンザリします)

自分は Jabra Elite 65t を利用しているのですが、これの運用がトテモ大変でした。
普段は付属の充電器にしまっておいて、会議の時間になると取り出す。ってのが macOS の頃の利用方法だったですが、WorkSpacesとなると勝手が違います。
原因は自分の利用しているデバイスが『充電器に入れた際に自動で電源が切れる』ことにあります。

# 理想
  1. 充電器からイヤホンを取り出す
  2. リモートミーティングに参加
  3. ミーティングが終了、イヤホンを充電器に戻す
  4. スピーカーから音楽をかけながら、個人タスクを進める
  5. 充電器からイヤホンを取り出す
  6. ミーティングに参加
# 現実
  1. WorkSpacesクライアントのセッションを切断
  2. 充電器からイヤホンを取り出す
  3. WorkSpacesへ接続
  4. リモートミーティングに参加
  5. ミーティングが終了、イヤホンを充電器に戻す
  6. スピーカーから音楽をかけながら、個人タスクを進める
  7. WorkSpacesクライアントのセッションを切断
  8. 充電器からイヤホンを取り出す
  9. WorkSpacesへ接続
  10. ミーティングに参加

って感じで、まあ面倒ですね。
チームメンバーとサクっと会話したい時って、当該のSlackチャンネルで『/call』ってタイプして、Slack Callが起動している間に充電器からイヤホンを取り出して会話の開始。って感じだったのですが、WorkSpaces では前記のような複雑な儀式が必要になってしまうので、ラフなコミュニケーションを多く取りたい。ってモチベーションを挫きますね。

そんなワケで、GoogleMeet には macOS 側から参加しています。
Webカメラも使えるし、WorkSpaces 側で開いているファイルも画面共有できるので、当面はこのアプローチで使っていこうと思います。

まとめ

この記事では詳細まで触れていませんが、Webカメラが利用できない部分も躊躇する要因のひとつです。
この問題については、↓こちらで紹介されているWSP (WorkSpaces Streaming Protocol) にて利用可能となるようです。(いまはベータ版)

Amazon WorkSpaces Streaming Protocol (ベータ版) の紹介

日々改善されていくのは AWS の素晴らしいところですね。
WorkSpaces の大ファンとしては、こちらで紹介した課題も早々に改善されるものと信じています。
 
いや~、WokrSpaces って本当にいいものですね。

SnowSQL コマンドで Snowflake に接続する

$
0
0

技術4課の宮本です。先日スタンディングデスクを導入したのですが、2日目にして何故か首を痛めてしまいました。人間の身体って脆いですね。

さて、今回は先日のブログ DWH製品の注目株!! Snowflake をさわってみた の続編です。前回はWebインターフェースでクエリを実行しましたが、今回はCLIクライアントである SnowSQL を試してみたいと思います。PostgreSQL でいうところの psql 、Oracle でいうところの sqlplus に相当するツールです。

SnowSQL のインストール

まずはインストールからです。https://docs.snowflake.com/ja/user-guide/snowsql-install-config.html にアクセスしてみましょう。

主要なプラットフォームに対応しているようです。

今回は手元の環境 (macOS Mojave 10.14.6) で試してみます。

$ brew cask install snowflake-snowsql

==> Downloading https://sfc-repo.snowflakecomputing.com/snowsql/bootstrap/1.2/darwin_x86_
######################################################################## 100.0%
==> Verifying SHA-256 checksum for Cask 'snowflake-snowsql'.
==> Installing Cask snowflake-snowsql
==> Running installer for snowflake-snowsql; your password may be necessary.
==> Package installers may write to any location; options such as --appdir are ignored.
Password:
installer: Package name is Snowflake SnowSQL
installer: Installing at base path /
installer: The install was successful.
🍺  snowflake-snowsql was successfully installed!

上手くいきましたね。インストールされたか確認してみます。

$ snowsql -v
Version: 1.2.5

無事インストールされているようです。

Snowflake に接続する

早速ログインしてみましょう。

$ snowsql -a XXXXXXXX.ap-northeast-1.aws -u miyamoto
Password:
* SnowSQL * v1.2.5
Type SQL statements or !help
miyamoto#COMPUTE_WH@(no database).(no schema)>

-a はアカウント名、-u はユーザー名を指定するオプションです。アカウント名の XXXXXXXX 部分はご自身のアカウント名に置き換えて下さい。(Webインターフェースにログインする際のURL https://XXXXXXXX.ap-northeast-1.aws.snowflakecomputing.com/console/login  で確認出来ます。)

アカウント名はプラットフォーム、リージョンによって微妙に形式変わってくるので、こちら のページの 地域別のアカウント名の例 を確認して下さい。

データベース、スキーマは選択されていない状態です。以下の様に設定します。

miyamoto#COMPUTE_WH@(no database).(no schema)>use database SNOWFLAKE_SAMPLE_DATA;
+----------------------------------+
| status                           |
|----------------------------------|
| Statement executed successfully. |
+----------------------------------+
1 Row(s) produced. Time Elapsed: 0.340s

miyamoto#COMPUTE_WH@SNOWFLAKE_SAMPLE_DATA.(no schema)>use SCHEMA TPCH_SF1;
+----------------------------------+
| status                           |
|----------------------------------|
| Statement executed successfully. |
+----------------------------------+
1 Row(s) produced. Time Elapsed: 0.666s

タイプするたびに補完候補が出てくれます。凄くよく出来ています。

ちなみにログイン時にデータベース(-d オプション)、スキーマ(-s オプション)を指定することも出来ます。

$ snowsql -a XXXXXXXX.ap-northeast-1.aws -u miyamoto -d SNOWFLAKE_SAMPLE_DATA -s TPCH_SF1
Password:
* SnowSQL * v1.2.5
Type SQL statements or !help
miyamoto#COMPUTE_WH@SNOWFLAKE_SAMPLE_DATA.TPCH_SF1>

クエリを実行する

miyamoto#COMPUTE_WH@SNOWFLAKE_SAMPLE_DATA.TPCH_SF1>SELECT * FROM CUSTOMER LIMIT 10;
+-----------+--------------------+---------------------------------------+-------------+-----------------+-----------+--------------+-------------------------------------------------------------------------------------------------------------------+
| C_CUSTKEY | C_NAME             | C_ADDRESS                             | C_NATIONKEY | C_PHONE         | C_ACCTBAL | C_MKTSEGMENT | C_COMMENT                                                                                                         |
|-----------+--------------------+---------------------------------------+-------------+-----------------+-----------+--------------+-------------------------------------------------------------------------------------------------------------------|
|         1 | Customer#000000001 | IVhzIApeRb ot,c,E                     |          15 | 25-989-741-2988 |    711.56 | BUILDING     | to the even, regular platelets. regular, ironic epitaphs nag e                                                    |
|         2 | Customer#000000002 | XSTf4,NCwDVaWNe6tEgvwfmRchLXak        |          13 | 23-768-687-3665 |    121.65 | AUTOMOBILE   | l accounts. blithely ironic theodolites integrate boldly: caref                                                   |
|         3 | Customer#000000003 | MG9kdTD2WBHm                          |           1 | 11-719-748-3364 |   7498.12 | AUTOMOBILE   |  deposits eat slyly ironic, even instructions. express foxes detect slyly. blithely even accounts abov            |
|         4 | Customer#000000004 | XxVSJsLAGtn                           |           4 | 14-128-190-5944 |   2866.83 | MACHINERY    |  requests. final, regular ideas sleep final accou                                                                 |
|         5 | Customer#000000005 | KvpyuHCplrB84WgAiGV6sYpZq7Tj          |           3 | 13-750-942-6364 |    794.47 | HOUSEHOLD    | n accounts will have to unwind. foxes cajole accor                                                                |
|         6 | Customer#000000006 | sKZz0CsnMD7mp4Xd0YrBvx,LREYKUWAh yVn  |          20 | 30-114-968-4951 |   7638.57 | AUTOMOBILE   | tions. even deposits boost according to the slyly bold packages. final accounts cajole requests. furious          |
|         7 | Customer#000000007 | TcGe5gaZNgVePxU5kRrvXBfkasDTea        |          18 | 28-190-982-9759 |   9561.95 | AUTOMOBILE   | ainst the ironic, express theodolites. express, even pinto beans among the exp                                    |
|         8 | Customer#000000008 | I0B10bB0AymmC, 0PrRYBCP1yGJ8xcBPmWhl5 |          17 | 27-147-574-9335 |   6819.74 | BUILDING     | among the slyly regular theodolites kindle blithely courts. carefully even theodolites haggle slyly along the ide |
|         9 | Customer#000000009 | xKiAFTjUsCuxfeleNqefumTrjS            |           8 | 18-338-906-3675 |   8324.07 | FURNITURE    | r theodolites according to the requests wake thinly excuses: pending requests haggle furiousl                     |
|        10 | Customer#000000010 | 6LrEaV6KR6PLVcgl2ArL Q3rqzLzcT1 v2    |           5 | 15-741-346-9870 |   2753.54 | HOUSEHOLD    | es regular deposits haggle. fur                                                                                   |
+-----------+--------------------+---------------------------------------+-------------+-----------------+-----------+--------------+-------------------------------------------------------------------------------------------------------------------+
10 Row(s) produced. Time Elapsed: 1.860s

テーブル形式で出力されます。キーワードを逐一補完してくれて最高です。

ctrl + d で接続を切ることが出来ます。

接続情報を設定ファイルで管理する

接続情報を都度入力するのは面倒ですよね。そんな時は設定ファイルを用意しましょう。Linux/macOS の場合は ~/.snowsql/config 、Windowsの場合は %USERPROFILE%\.snowsql\config ファイルを開いて以下の様に追記します。

[connections.conn1]

accountname = XXXXXXX.ap-northeast-1.aws
username = miyamoto
password = your-password
dbname = SNOWFLAKE_SAMPLE_DATA
schemaname = TPCH_SF1

[connections.<name>] は接続情報を記載するセクションを意味します。接続情報には任意の名前をつけることが出来ます。(今回はconn1 という名前を付けました。)

パスワードは平文で保存される為、configファイルの取り扱いに注意して下さい。例えば、Linux/macOS の場合に chmod 700 ~/.snowsql/config の様に最小限のPermission を設定し、他のユーザーからは参照できない様にする等の対策を行いましょう。

用意したconfigを利用したログインを試してみます。

$ snowsql -c conn1
* SnowSQL * v1.2.5
Type SQL statements or !help
miyamoto#COMPUTE_WH@SNOWFLAKE_SAMPLE_DATA.TPCH_SF1>

-c オプションでconfigファイルに記載した接続情報の名前を指定します。

まとめ

SnowSQL で Snowflake にアクセスする方法をご紹介しました。タイプする度に補完候補が表示されるので、使っていて非常に気持ちの良いツールです。

次回は Python からのアクセスを試してみたいと思います。

Route 53がAWS中国(寧夏)リージョンで利用可能になりました

$
0
0

2020年5月13日のアップデート

AWS中国(寧夏)リージョンで利用可能になりました。
Amazon Route 53 is now available in AWS China (Ningxia) Region, Operated by NWCD

Route 53は基本的なサービスであり、中国に今までなかったのかと驚くかもしれませんが、そう、無かったんです。
そしてついに利用できるようになりました。

AWSグローバルアカウントと中国アカウントのRoute 53を比較

マネージメントコンソールで比較しました。
利用できるようになったといっても、完全に同じというわけではありませんでした。

AWS中国の公式ドキュメントに、AWSグローバルアカウントとの違いについて記載があります。
以下、機械翻訳ですが、引用します。

・Route 53を使用してドメインを登録することはできません。ただし、中国のリージョンの1つにホストゾーンを作成し、そのホストゾーンのネームサーバーを、グローバルアカウントを使用して登録したドメインまたは別のドメインレジストラーに登録したドメインに関連付けることができます。

・トラフィックフローは利用できません。

・パブリックDNSクエリログは使用できません。

・パブリックホストゾーンのDNSクエリメトリックは使用できません。

・トラフィックをAmazon S3バケットまたはAmazon API Gateway APIエンドポイントにルーティングするエイリアスレコードを作成することはできません。

・中国リージョン外のAWSリソースにトラフィックをルーティングするエイリアスレコードを作成することはできません。

・geoproximityルーティングポリシーを使用するレコードを作成することはできません。そのルーティングポリシーは、トラフィックフローに対してのみ使用できます。

・Route 53リゾルバーを使用して、VPCからネットワークに、またはネットワークからVPCにDNSクエリを転送することはできません。

・プログラムでエイリアスレコードを作成し、Amazon CloudFrontディストリビューションにトラフィックをルーティングする場合は、次のホストゾーンIDを使用しますZ3RFFRIM2A3IF5。

Feature Availability and Implementation Differences

AWS中国も進化しています。

遠い昔にAWS中国の利用を検討した方は、使えるサービスが少ないなーと思われたかもしれません。
今でも相対的には少ないわけではありますが、それでも意外と継続的にサービスが充実し続けています。

大きなところでは、2019年4月にはCloudFrontが使えるようになりましたね。
Amazon CloudFront is now Available in Mainland China

AWS中国のアップデート情報もグローバルと同じようにWhat’s New with AWSに出てきます。
China でフィルタすると、意外とたくさんでてきます。


ALB 配下の EC2 インスタンスを Active Standby 構成(自動切り替え)にする

$
0
0




ELB 配下の EC2 インスタンスを Active Standby 構成にする.md



ALB 配下の EC2 インスタンスを Active Standby 構成(自動切り替え)にする

ALB配下の EC2インスタンス を 2台に冗長化するときに 1台をコールドスタンバイにして障害時に自動切り替えする構成を考える場面がありました (1,2)

  1. ALB配下に EC2インスタンスが 2台以上同時稼働する構成にバックエンド側が対応できない
  2. 2台分の料金を支払いたくない

ALB のロードバランシングアルゴリズム

ALBのリクエスト振り分け方式 ( ロードバランシングアルゴリズム ) は 以下の2つのいずれかになります

  1. ラウンドロビン → すべてのターゲット( EC2インスタンス ) を対象にして順繰りにリクエストを送信
  2. 最小の未処理のリクエスト → 未処理のリクエスト数が最も少ないターゲット( EC2インスタンス ) にリクエストを送信

下の図のように 1台の EC2インスタンスをコールドスタンバイにして自動切り替えする事はできません
※ 例えば 「Availability Zone A に起動している EC2インスタンス が ALBからのヘルスチェック で Unhealthy になったら Availability Zone B に自動で新しく起動」ということは出来ません

※ 自動切り替えは不可なものの手動では出来ます (コールドスタンバイのインスタンスをターゲットグループから外しておき 障害発生時に手動でターゲットグループに入れることで実現可能です)

Auto Scaling グループを使ってActive Standby 構成(自動切り替え)を実現する

Auto Scaling グループを使ってActive Standby 構成(自動切り替え)を実現できます
実際に以下のように切り替わるようにます

  1. 運用中の EC2インスタンス が ALB からのヘルスチェックに失敗
  2. ALB からのヘルスチェックに失敗した EC2インスタンス を 削除
  3. 新しく EC2 インスタンス を 1台起動 ( ap-northeast-1a または ap-northeast-1c )

具体的な設定は以下のようにします

  1. アベイラビリティーゾーン :ap-northeast-1a, ap-northeast-1c
  2. ヘルスチェックのタイプ :ELB
  3. ターゲットグループ:ELBのターゲットグループ
  4. 希望するキャパシティ:1
  5. 最小キャパシティ:1
  6. 最大キャパシティ:2
  7. 終了ポリシー :default

※削除中に新しいインスタンスを起動できるように「最大キャパシティ」を2に設定しています

作成した構成を図示します

Availability Zone (AZ) 障害対策となるか?

Availability Zone (AZ) 障害対策となるか?という観点でドキュメントに以下のような記述がありました

1 つのアベイラビリティーゾーンが異常ありまたは使用不可になると、Amazon EC2 Auto Scaling は、影響を受けていないアベイラビリティーゾーンで新しいインスタンスを起動します。異常のあるアベイラビリティーゾーンが正常な状態に戻ると、Amazon EC2 Auto Scaling は Auto Scaling グループのアベイラビリティーゾーンにわたって均等にインスタンスを自動的に再分散します。Amazon EC2 Auto Scaling は、インスタンス数が最も少ないアベイラビリティーゾーンで新しいインスタンスの起動を試みることで、これを実行します。この試みが失敗すると、Amazon EC2 Auto Scaling は成功するまで他のアベイラビリティーゾーンでの起動を試みます。

以上より 例えば ap-northeast-1a に AZ 障害が起きたときには 以下の動作になるようです

① ap-northeast-1a の EC2インスタンスが unhealthyになる
② ap-northeast-1c に EC2インスタンスが起動する

但し 「AZ障害」 自体の定義が難しいため以下は念頭においたほうが良さそうです

  • 「AZ 障害」は様々な事象が考えられ、状況によって考慮点も広範囲に渡る
  • AZ 障害時に確約的に ELB のヘルスチェックが失敗するとは限らない

参考

誰かのお役に立てますと幸いです


Step Functionsで Lambda のタイムアウトエラーをキャッチして再試行する

$
0
0

はじめに

こんにちは。技術4課の河野です。
今回は、AWS Step Functions(以下「SFN」) で AWS Lambda(以下「Lambda」) がタイムアウトした場合に、再試行する方法について紹介します。
AWS公式ドキュメントにも、事前にエラー処理をステートマシンに定義することがベストプラティクスと記載されています。
もちろん、タイムアウト以外にも想定されるエラーはきちんと定義しておきましょう。

目次

  • 作成するものについて
  • 手順
    • Lambda 作成
    • SFN 作成
    • 動作確認
  • まとめ

作成するものについて

今回は、以下のような単純なステートマシンを定義します。
ステートマシンが Lambda を呼び出し、呼び出した Lambda がタイムアウトした際に再試行します。

今回はServerlss Framework というサーバレスアプリケーションの構築管理ができる
無料のオープンソースを使用して構築及びデプロイを行います。
インストール方法などの各種準備については割愛します。詳細については、弊社過去記事を参考にしていただければ幸いです。

手順

Lambda 作成

まずは、10秒間待機させる単純な関数を作成します。

import time


def handler(event=None, context=None):

    # 10秒待機
    time.sleep(10)
    return {}

予め Lambda のタイムアウト時間を5秒に設定することで、タイムアウトエラーを発生させます。

SFN 作成

次に、ステートマシンを定義します。
最初に示したワークフローを作成するには、serverless.yml を下記のように編集します。

service: stepfunctions
provider:
  name: aws
  runtime: python3.8
  stage: dev
  region: ap-northeast-1

plugins:
  - serverless
  - serverless-step-functions

package:
  include:
     handler.py
  exclude:
    - node_modules/**
    - .serverless/**

functions:
  timeoutSample:
    handler: handler.handler
    name: ${self:provider.stage}-timeout-sample
    timeout: 5

stepFunctions:
  stateMachines:
    myStepFUnctions:
      name: myStepfunctions
      definition:
        StartAt: executeFunction
        States:
          executeFunction:
            Type: Task
            Resource:
              Fn::GetAtt: [timeoutSample,Arn]
            TimeoutSeconds: 60
            ResultPath: '$'
            Retry:
            - ErrorEquals:
              - 'Lambda.Unknown'
              IntervalSeconds: 1
              MaxAttempts: 2
            End: True

再試行は、上記のRetryフィールドで定義しています。
設定している各パラメータについて解説します。

ErrorEquals

キャッチするエラーを指定します。ステートマシンの実行結果と指定したエラーが一致した場合に再試行されます。
メモリ不足や関数タイムアウトなどの Lambda で処理されないエラーは、Lambda.UnknownStates.ALL または、States.TaskFailed で一致できます。
その他の Lambda に関するエラーはAWS Lambda Developer Guideを参考にしてキャッチするエラーを指定することができます。

IntervalSeconds

初回の再試行までの時間です。2回目以降は、BackoffRate の設定値によって増加します。

MaxAttempts

再試行の最大回数になります。最大回数を超えると、ステートマシーンでエラーとなり処理が終了します。

それでは、デプロイして実際の動作を確認していきましょう。

動作確認

2回の再試行後、ステートマシンが終了していることを確認できました。

まとめ

今回は、StepFunctions で再試行する方法について紹介しました。

  • エラー処理はステートマシンに事前に定義しておく
  • 再試行はRetryフィールドで定義できる
  • ErrorEqualsにキャッチするエラーを指定する

最後まで読んでいただきありがとうございました。

Direct Connect VIFのCloudWatchメトリクスが見られるようになりました

$
0
0

技術三課の杉村です。AWS環境の運用者にとって嬉しいアップデートがありました。

AWS Direct Connect の強化されたモニタリング機能

AWS Direct Connect をご利用のお客様は、CloudWatch メトリクスを使用して、AWS Direct Connect 仮想インターフェイス (VIF) の使用状況、状態、正常性を監視し、アクションを実行できるようになりました。

従来は、Direct Connect の「Connection(物理接続、いわゆる土管)」の接続状態・トラフィックスループット・光レベルをCloudWatchで確認することができました。
しかしながらVIFのデータ流量等を見たい場合は、オンプレのルータ側でSNMPなどで取得したデータを頼りにするしかありませんでした。
(回線キャリアによっては、これを確認できるコンソール画面を提供している場合もあります)

今回のアップデートで Connection だけでなく、 Virtual Interface (略してVIF。Connectionの中を通る論理接続) の bps (bits per second) と pps (packets per second) を確認できるようになったのです。

1. VIFってなんだっけ…

ところで、Virtual Interface(VIF)とはなんでしたっけ。
Direct Connect関連の仕様は、以下のブログを順に読んでいくと分かりやすいかもしれません。
VIFの概念だけであれば、No 1のブログをお読みください。

  1. AWS Direct Connectの概念の整理…Connectionとは?VIFとは?
  2. DX系サービスの変遷とAWS Transit Gatewayの嬉しいところ

  3. AWS Transit GatewayとDirect ConnectのマルチAWSアカウント構成

  4. Transit Gatewayで実現するマルチリージョン構成・マルチアカウント構成

これまでCloudWatchで状態を見ることができた Connection とは物理回線のことであり、その “土管” の中に論理回線である Virtual Interface(VIF) が通っていて、VIFの中を実際のデータが行き来しているとイメージしてください。

2. 何がうれしいの?

2-1. ユースケース

以下のようなときに、VIFのデータ流量を確認したくなるでしょう。

  • ネットワークメンテナンスの時間を決めるとき
    • 利用が最も多い・少ない時間帯を特定できる
  • トラブルの発生時の切り分け
    • オンプレとデータをやりとりするバッチ処理で遅延が… どこで詰まっている?
    • 昨日の夜中、回線が一時断絶したらしい。何時ころに起こった?
  • 回線増強の検討時
    • 今時点でどのくらい使われていて、どのくらいまで増やせばよさそう?

2-2. Hosted Virtual Interface でもマネコンでデータ流量を確認できる

AWS Direct Connectのいわゆる「共有型回線」のサービスをパートナーと契約して利用している場合、前掲の 1. のブログの Hosted Virtual Interface というものに該当している場合があります。
このパターンの場合、Connection はサービス提供者が持っており、利用者は VIF の払出を受けて利用します。
利用者のAWSアカウントからは Connection が見られないため、 Connection の CloudWatchメトリクス も当然見られません。

つまりこのパターンの場合ですと、以前は利用している Direct Connect の利用状況が見えな(モニタリングできな)かったわけです。
(前述のとおり、回線キャリア等の情報を頼りにしていました)

今回のアップデートでは VIF 単位で情報が見ることができるようになりましたので Hosted Virtual Interface を利用している場合でも、AWSマネジメントコンソールでデータ流量が確認できます。

3. 閲覧手順

  1. サービス一覧から「CloudWatch」を選択しCloudWatchのコンソールへ遷移します

  2. 左部ペインから「メトリクス」をクリックします

  3. 下部ペインから「DX」をクリックします(なおDXとはDirect Connectの略称です)

  4. 下部ペインから「仮想インターフェイスメトリクス」をクリックします

  5. 下部ペインにAWSアカウント内のVIFとそのメトリクスの一覧が現れます。必要なメトリクスを選択し、グラフを表示します

Amazon Kendra が一般利用可能 (GA) になりました!

$
0
0

はじめに

こんにちは、技術1課の山中です。
家に眠っていた RTX1500 を引っ張り出してきてリモートで同僚のアドバイス通り設定したらネットが更に速くなりました。 (といっても 100M が限界ですが…

今回は Amazon Kendra が一般利用可能になったということで触っていきたいとおもいます。

Amazon Kendra が一般利用可能に

Amazon Kendra とは

Amazon Kendra は S3 や RDS もしくは、 SharePoint などの外部サービスにあるデータを機械学習で分析してユーザからの質問に返してくれる検索サービスを提供してくれます。

「住宅手当をもらえる条件は?」、「本を買うときの稟議の回し方は?」などユーザが問い合わせると、解析したデータからよりよい回答を探し出してくれるみたいです。めちゃめちゃ便利そうですね!!!

サポートしているデータソース (2020/05現在)

現在は以下データソース向けの Kendra コネクタが提供されています。

  • S3
  • SharePoint
  • Salesforce
  • Servicenow
  • RDS データベース
  • One Drive

今年の後半には対象が増える予定とのことですので、期待しておきましょう。

サポートされるファイルタイプ (2020/05現在)

Amazon Kendra は以下ファイルタイプをサポートしています。

  • .html
  • MS Office (.doc、 .ppt)
  • PDF
  • テキスト形式の非構造化および半構造化データ

対応リージョン (2020/05現在)

Amazon Kendra は以下リージョンで利用可能です。

  • 米国東部 (バージニア北部)
  • 米国西部 (オレゴン)、
  • 欧州 (アイルランド)

対応言語 (2020/05現在)

Amazon Kendra は 英国英語 のみをサポートしています。
早く日本語に対応してほしいですねー

料金

Amazon Kendra には 2 つのエディションが存在し、それぞれ以下の違いがあります。

Developer Edition Enterprise Edition
ドキュメントのストレージ 最大 10,000 ドキュメント 最大 500,000 ドキュメント
1 日あたりの最大クエリ件数 4,000 40,000
データソース 5 50
アベイラビリティーゾーン 1 3
無料利用枠 最初の 30 日間で最大 750 時間の無料利用枠 該当なし
料金 (1 時間単位の請求) 2.50 USD/時間 7.00USD /hour
料金 (1 か月単位の請求) 1,800 USD/月 5,040.00USD/month
追加キャパシティー追加クエリバンドル なし 1 日あたり 40,000 件の追加クエリごとに 3.50 USD/時間
追加キャパシティー追加ドキュメントストレージバンドル なし 500,000 の追加ドキュメントごとに 3.50 USD/時間
スキャンされたコネクタ使用ドキュメント 4,000 40,000
1 日あたりの最大クエリ件数 スキャンされたドキュメントごとに 0.000001USD スキャンされたドキュメントごとに 0.000001USD
同期時のコネクタの使用 同期時のコネクタごとに 1 時間あたり 0.35USD 同期時のコネクタごとに 1 時間あたり 0.35USD

検索インデックスを作成後、プロビジョニングから削除までの時間に応じて上記の料金が発生します。
Kendra Developer Edition は 単一のアベイラビリティゾーンで実行であったり、キャパシティの追加ができなかったりなど、 PoC 構築時の低価格オプションということなので開発時以外は Kendra Entarprise Edition を選択することが推奨されています。

試してみる

試してみないとわからない!ということで試していきましょうー!
今回は バージニア北部リージョン にて作成します。

事前準備

今回はデータソースに S3 を指定するので、事前にバージニアリージョンに S3 バケット 20200518-kendra-demo を作成しデータを格納しています。
データは サーバーワークスエンジニアブログ の html ファイルを Amazon Translate で英語に翻訳したものを格納しています。
※ 10 ファイル程度

インデックスを作成する

Amazon Kendra を開くと以下ページが開くので Create an Index ボタンをクリック

Create index ボタンをクリック

インデックス名と CloudWatch log にアクセスするための IAM ロールを指定します。
今回 IAM ロールは新規に作成します。

次の画面ではエディションを選びます。今回は試すだけなので Developer edition を選択します。

Create ボタンをクリックすると、 30 秒ほど待ちます。

画面が遷移し、インデックスの作成が始まるので 30 分ほど待ちましょう。

これでインデックスの作成は完了です!

データソースをインデックスに追加する

インデックス作成後の画面からAdd data source ボタンをクリックし、データソースを追加します。
左ペインから Data sources を選択して、対象のサービスにて Add connector ボタンをクリックでも追加することができます
各データソースの追加ステップ数が記載されていてとても親切です。
今回は Amazon S3 のカードから Add connector ボタンをクリックします。

追加するデータソースの名前を入力し、 Next ボタンをクリックします。

S3 コネクタの設定を行います。
データが格納されている S3 バケットを指定し、 Amazon Kendra から S3 へアクセスするための IAM ロールを指定します。
※ S3 バケットは Amazon Kendra を作成するリージョンと同じリージョンである必要があります。
今回は先程と同様に IAM ロールを新規に作成しています。
また、データを同期するタイミングもカスタマイズ可能です。
今回はオンデマンドを指定していますが、毎時、毎日、毎週など指定することができます。

最後に、設定項目を確認し問題なければ Create ボタンをクリックします。

また 30 秒ほど待つと

データソースの追加が完了するので、 Sync now ボタンをクリックし、同期を始めましょう。

しばらく経つとインデックスへデータが追加されます。

インデックスを検索する

Search console から早速検索してみます。
まずは、検索ボックスにaws update と入力してみましょう。
そうすると、ちゃんと結果が返ってきました!!

おわりに

今回はお試しということで、対象のデータは少なかったですが、 Salesforce や SharePoint などとも簡単に連携できるので色々なところに散らばっているデータを Aamazon Kendra を利用するとうまく活用できるようになりそうですね!!

また、この内容は 2020/5/20(水) 12:00 よりYouTube Liveで配信する「30分でわかる AWS UPDATE!」で取り上げます!
是非ご覧ください!

参考

WorkSpacesでマイクロソフトOfficeを1時間で使えるようにしてみる

$
0
0

SRE部の前田と申します。
突然ですが、WorkSpacesを1時間で立ててマイクロソフトOfficeを利用できるようにしてみます。
何をしているか分かるようにCloudFormationを利用せず、AWSマネジメントコンソールでポチポチします。
WorkSpacesを使うためのDirectory Serviceの作成に10分ほど、WorkSpacesは使うぞとポチってから利用できるまで20分ほどかかりますので、逆算して30分で整えます。

開始0:00〜0:12

AWSマネジメントコンソールにログインして「Directory Service」を選択します。
WorkSpacesは、WorkSpacesmマシンと利用ユーザの管理にActive DirectoryのようなDirectory Serviceを利用しています。
WorkSpacesを構築するところでDirectory Serviceがなければ作れるのですが、工程が分かりやすいように先に作ります。

まだDirectory Serviceは1つもないので作ります。

WorkSpacesを利用できれば良いので最もシンプルな「Simple AD」を選択します。
他サービスにDirectory Serviceを提供したり、既存のActive Directoryと連携させたい場合は「AWS Managed Microsoft AD」を選択します。
既存のDirectory Serviceを利用する場合は「AD Connector」を選択します。
ユーザ認証でGoogleやFacebookのようなIDプロバイダを利用する場合は「Amazon Cognitoユーザープール」を選択します。

ディレクトリのサイズやDNS名などを入力します。

先の選択で「Amazon Cognitoユーザープール」以外を選択した場合、ディレクトリサービスを行うEC2インスタンスを内部的に立てます。
このEC2インスタンスとこの後構築するWorkSpacesインスタンスを設置するVPC・サブネットを指定します。

ここまで指定した内容はDirectory Service構築後に修正できません。(作り直しになります)
確認してよければ「ディレクトリの作成」をクリックして作成します。

作成されるまで5〜10分かかるとのことなので待ちます。

ステータスが「作成中」から「アクティブ」になりましたらDirectory Serviceを使えるようになります。

開始0:12〜0:37

AWSのメニューから「WorkSpaces」を選択してWorkSpacesの画面に移動します。
まだWorkSpacesは1台もないところで「WorkSpacesの起動」をクリックしてWorkSpacesの作成を開始します。

構築するWorkSpacesをどのサブネットに設置するか、WorkSpaces利用ユーザにWorkSpacesの再設定を許すかなどを選択します。
これは構築したDirectory ServiceでWorkSpacesを利用する初回のみで2回目以降は今回設定した内容が適用されます。

まだWorkSpacesを利用するユーザは作っていないため、「新規ユーザーを作成して〜」の欄にユーザー名等を入力してユーザを作成します。

予め必要なアプリを導入して利用してもらえるようにバンドルを作成しておくこともできます。
今回はOfficeが使えれば良いという想定で、Office入りのバンドルを選択します。

月額料金にするか時間料金にするか、時間料金にする場合使われなくなってからどのくらいの時間が経過したらWorkSpacesを停止するかの指定、ストレージを暗号化するかを指定します。料金については構築後に変更できます。
どのユーザが使っているか分かりやすくなるようにタグをつけておきます。

ここまでの設定内容の確認です。良ければ「WorkSpacesの起動」をクリックしてWorkSpacesを構築します。

WorkSpacesが使えるようになるまで20分ほどかかるとのことなので待ちます。

ステータスが「PENDING」から「AVAILABLE」になりましたらWorkSpacesを使えるようになります。

開始0:37〜0:52

「AVAILABLE」になると、先に登録したユーザー宛に招待メールが届きます。
招待メールにあるリンクをクリックすると、パスワード設定が求められます。
※パスワードは英大文字、小文字、記号、数字の組み合わせが必要になります。

パスワードの更新が終わるとWorkSpacesクライアントのダウンロード画面に遷移しますので、クライアントをダウンロードしてインストールします。(クライアントのダウンロードとインストールは初回のみです)
クライアントにてメニュー「Options」から「Manage Registrations」を選択し、メールにある登録コードを設定します。

招待メールにあるユーザー名と先に設定したパスワードを入力しWorkSpacesにサインインします。

WorkSpacesの初回起動時に「このネットワーク上の〜」と表示されますが、「はい」を選択して問題ありません。

エクセルやワードが使えるようになりました。

使い終わりましたら、いわゆる普通のWindowsと同様にスタートメニューからシャットダウンするだけです。

まとめ

WorkSpacesを1時間で利用できるようになんとかなりました。
このように、ひとまず使えれば良いでありましたらお気軽スピーディに使えるようになります。
既存のActive Directoryのユーザ情報を利用したいのような場合ですと、構成が複雑になり1時間ではさすがに厳しいですが、それでも一度構築すればWorkSpacesを利用するユーザに応じて増やすだけの作業になります。
がっつり使う場合は月額固定を、1日少ししか利用しないなら時間料金をと、ニーズに応じて使い分けができますし事前の見積もりもしやすくなります。
お気軽に使えると言われても、設定してみて使えるようになったが、これで設定が正しいのか…?となることがあると思います。
弊社ではWorkSpaces導入を通じてリモートワーク導入・運用のお手伝いを行っておりますのでよろしければお声がけください。

Amazon Macieが東京リージョンで利用可能になり80%以上値引きされました!

$
0
0

こんにちは、技術1課の小倉です。
2020/5/13にアップデートがあり、Amazon Macieが東京リージョンで利用可能になり80%以上値引きされました!

Announcing major enhancements to Amazon Macie, an 80%+ price reduction, and global region expansion

また、本アップデートで機能強化が行われ、追加された機能です。

  • 個人情報(PII)検出のための機械学習モデルの更新、正規表現を使用した顧客定義のセンシティブデータタイプなどの検出機能の拡張
  • AWS Organizationsによるマルチアカウントのサポート
  • AWS SDKやAWS CLIを利用してプログラム的に利用するためのAPIをカバー
  • 利用可能なリージョンが17に拡大(東京リージョン含む)
  • 新しい簡素化された無料枠
  • 完全に再設計されたコンソールとユーザーエクスペリエンス

AWS公式ブログ : New – Enhanced Amazon Macie Now Available with Substantially Reduced Pricing

Amazon Macieとは

機械学習を使用してS3バケットに保管されているデータを自動的に特定および分類することで、機密データを検出して保護するのに役立つフルマネージドサービスです。

AWS公式サイト : Amazon Macie

ドキュメントを確認しましたが、Macieで検出できる個人識別情報(PII)に日本の運転免許証が含まれていませんでした。また、対応言語もドキュメントを見ても記載は見つけられませんでしたので、おそらく日本語対応されていないと思います。

AWS公式サイト : Managed data identifiers in Amazon Macie – Personal identifying information

料金は評価対象のAmazon S3バケット数と機密データ検出のデータ処理量の2つでかかりますが、以前よりもかなり安くなっています(以前はバージニアで$5/GB)。最新の料金はAWS公式サイトでご確認ください。また、S3バケット数は30日の無料利用枠がありますが、機密データ検出のデータ処理量は毎月の1GBの無料枠のみです。

AWS公式サイト : Amazon Macie の料金

設定手順

マネジメントコンソールにログインして、Amazon Macieのサービス画面を開きます。
[Get started]をクリックします。

[Macieを有効化]をクリックします。

これでMacieが有効化され、ダッシュボードが表示されます。

S3バケット内のデータのチェックをするためにジョブを作成します。
左メニューの[S3バケット]をクリックし、チェック対象のS3バケットを選択し、右上の[ジョブを作成]をクリックします。

選択したS3バケットの確認画面がでるので、内容を確認して[次へ]をクリックします。

スコープの画面で、今回はワンタイムジョブを選択し、[次へ]をクリックします。
スケジュールされたジョブを選択することで、定期的にジョブを実行することができます。
また、サンプリング深度は100%ですべてのデータをチェックしますが、数値を下げるとそのパーセンテージになるようにランダムにデータをチェックします。

カスタムデータ識別子の画面が表示されるので、[次へ]をクリックします。
正規表現を使って、カスタムデータ識別子を作成して、機密データを定義することができます。今回は作成していないので、そのまま次に進んでいます。

名前と説明の画面で、ジョブ名(今回はMacieTest)を入力して、[次へ]をクリックします。

確認して作成画面で、内容確認して問題なければ、[送信]をクリックします。

ジョブ一覧の画面が表示されます。ジョブの実行完了までには時間がかかります(私の環境だと2時間くらい)。
[結果を表示]をクリックすると結果を確認できます。

以下のように実行結果を確認できます。

まとめ

Amazon Macieが東京リージョンで利用可能になり80%以上値引きされました。S3バケットの現状や機密情報を含むデータを自動で確認できます。ただおそらく、まだ日本語対応はされていないので、確認できるのは英語とクレジットカード情報などの機密情報になるかと思います。価格がかなり安くなっていますので、機密情報をS3で取り扱っている方は利用してみてはいかがでしょうか。

また、本ブログの内容は2020/5/20(水) 12:00よりYouTube Liveで配信される「30分でわかる AWS UPDATE!」でも取り上げる予定ですので、ぜひご覧ください!
もしリアルタイムで見逃しても、アーカイブ動画から内容を確認できます。

【Amazon Connect】履歴メトリクスでなにができるの?

$
0
0

CI部の村上です。Amazon Connect初学者の私ですが、最近、検証目的で触る機会が増えてきました。

前の仕事でフリーダイヤルの契約をイチから担当したことがあるので分かるのですが、本当に短時間でコールセンターをつくることができるので、初めて触ったときは感動しました。

「じゃあコール数とかの分析も簡単にできるのかな?」とふと思ったので検証してみたら、これまた簡単だったので紹介したいと思います。

そもそも履歴メトリクスってなに?

以下はドキュメントからの引用です。「コールセンターの分析をしたいなら履歴メトリクスを見る」でOKそうですね。

履歴メトリクスレポートには、コンタクトセンターの過去の完了したアクティビティ、およびパフォーマンスに関するデータが含まれます。Amazon Connect には、すぐに使用できる組み込みの履歴レポートが含まれています。独自のカスタムレポートを作成することもできます。

履歴メトリクスレポート
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/historical-metrics.html

ドキュメントにも記載がありますが、履歴メトリクスのレポートは、設定を自由にカスタマイズすることができます。よって着信実績に基づくデータだけでなく、エージェント(オペレータのこと)のアクティビティに関するデータも出力することができます。

なお、ドキュメントにはところどころコールセンター用語が出てきます。初学者ゆえ私も「訳わからん」ってなるときがありますが、そんなときは下記のブログがとても参考になります。ご査収ください。

Amazon Connect 用語辞典 2018春
http://blog.serverworks.co.jp/tech/2018/05/15/connect-dictionary/

履歴メトリクスを見る方法

具体的な手順を紹介していきます。

まずAmazon Connectにログインし、メニューから「履歴メトリクス」を選択します。

すると以下のような画面に遷移します。

  • キュー
  • エージェント
  • 電話番号

以上の3つが表示されますので、表示したいものを選択します。今回は「キュー」を選択します。するとキューごとのメトリクスが表示されます。

 

これだけでも、「このキューの問い合わせ件数が多い」とか「あのキューの電話は長くなりがち」とか、いろいろなことが分かります。

次に右上にある歯車のマークを選択します。ここから表示するメトリクスデータを自由にカスタマイズすることが可能です。

  • 間隔&時間・・・メトリクスを集計する時間や間隔の設定が可能です。
  • グループ分け・・・「キュー」や「エージェント」など、どのグループに関するメトリクスを集計するか選択できます。
  • フィルター・・・集計したメトリクスに対してフィルタリングができます。
  • メトリクス・・・表示するメトリクスを選択できます。

以上の設定を変更して、自分好みの履歴メトリクスを表示させることができます。特に「メトリクス」にはとても多くの項目がありますので、様々な角度からコールセンターの状況を分析できそうです。「メトリクス」の種類についてはドキュメントを参照してください。

履歴メトリクスの定義
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/historical-metrics-definitions.html

例えばどんな履歴メトリクスが出力できるの?

想定シーンその1:お客様の待ち時間をキューごとに知りたい

私も経験がありますが、コールセンターに電話してからエージェントに繋がるまでの、謎の音楽鑑賞タイムは地獄です。

お客様の満足度をあげるためにもエージェントに繋がるまでの待ち時間は減らしたいもの。そのためには、キューごとの混雑状況を把握し、適切にエージェントを配置する必要があります。

そこで、メトリクスの項目から「平均キュー応答時間」、「対応した問い合わせ」を含む履歴メトリクスを出力すれば、お客様の平均待ち時間と問い合わせ件数を知ることができます。また、時間間隔は30分ごとに設定することもできるので、キューごとに混雑しやすい時間帯を把握することも可能です。

状況に応じてエージェントの人数や配置を変更すれば、お客様の待ち時間を減らせますね。

想定シーンその2:エージェントの電話待ち時間や電話以外の事務作業時間を知りたい

例えば、エージェントが電話だけでなく契約や解約手続きに関する業務も担当しているとします。

その場合、エージェントを豊富に配置していても、電話以外の事務手続きに時間をとられていては、結果的にお客様の待ち時間が増えることになってしまいます。

そこで、「エージェントのアイドル時間」、「連絡作業後の平均時間」などを含むメトリクスを出力すれば、エージェントが電話を待っている時間と電話以外の業務をしている時間を知ることができます。

  • 「エージェントのアイドル時間」は、エージェントのステータスがAvailableの状態である時間を指します。つまり電話をとれる状態です。
  • 「連絡作業後の平均時間」は、エージェントのステータスがAfter Call Workの状態である時間を指します。電話対応後の事務処理時間ですね。

上記のようにすることで、「電話対応後の事務処理に時間がかかっている」などの課題を見つけることができます。

レポートの保存は出来るの?

もちろんできます。

  • 名前を付けて保存(S3に保存)
  • CSVのダウンロード
  • レポートの共有(レポートの共有リンクが発行されます)
  • スケジュール(S3への保存をスケジューリングできます)

まとめ

AWSのサイトには「数百万の顧客をサポートするように拡張できるコンタクトセンターを数分で設定」とキャッチーな売り文句がありますが、履歴メトリクスレポートも簡単に出力できることが分かりました。


Amazon CloudSearchとAmazon Elasticsearch Serviceを実際に触ってみた

$
0
0

こんにちは!技術2課、濱岡です。

どうぶつの森の島クリエイターで時間がとけていってます。
でも、色々やっていると楽しくなっていってしまうんですよね。。。

さて、今回はAmazon CloudSearchとAmazon Elasticsearch Serviceの2つを実際に触ってみました。

Amazon CloudSearchとは

Amazon CloudSearchとはウェブサイトまたはアプリケーション向けの検索ソリューションを容易かつコスト効率良く設定、管理、スケールできるマネージド型のサービスになります。
34言語をサポートしており、ハイライト表示、自動入力、地理空間検索などもできるそうです。
日本語もちゃんとサポートしてます。

色々書きましたが、使った方が早いよねということで早速使ってみます。

Amazon CloudSearchを使ってみよう

ドメインを作成してみよう

サンプルのデータがあるのでこちらを参考にやっていきます。

まずAmazon CloudSearchのマネージドコンソールの画面から Create a new search domain を押します。

Search Domain Nameは好きな名前で大丈夫です。
私はtest-domainとしました。
他の値はdefaultにしました。
設定が終わったらContinueを押します。

次はindexの設定です。
Use a predefined configurationを選択します。
Load configuration for indexingはIMDb movies (demo)を選択します。
設定が終わったらContinueを押します。

設定の確認画面がでてきますので確認できたらContinueを押します。

最後にポリシーの選択ですね。
ちょっとここがわかりにくくて戸惑いました。

Search and Suggester service: Allow all. Document Service: Account owner only.を押します。

するとこんな感じでポリシーが表示されます。
これで大丈夫です。
そしてContinueを押します。

設定の確認画面がでてきますので確認できたらContinueを押します。

するとこんな画面にいきます。
ドメインの作成に10分ほどかかると書いてますね。
OKをクリックして10分ほど待ちます…

この画面から

この画面になれば作成できてます。

データのアップロードをしてみよう

今回はサンプルのデータを使用します。
Upload Dcumentsを押します。

Predefined dataを選択し、Load sample data forの部分はIMDb movies (demo)を選択します。
そしてContinueを押します。

確認画面がでますので確認したらUpload Documentsを押します。

この画面になりましたらFinishを押します。

実際に検索してみる

では、実際に検索してみます。
Run a test searchに検索したいワードを記入します。
私はためしにmarsで検索してみます。
ワードを記入したらGoを押します。

こんな感じで検索結果がでました。
次にmars attacksで検索してみます。

2つの画像をみると_scoreという値があります。
これは類似度でどれくらい情報が一致しているかという値ですね。
検索結果の表示順などに使っている値になります。

他にもOptionsを押すとand検索やor検索なんかもできます。

では、次にAmazon Elasticsearch Serviceを実際に使ってみましょう。

Amazon Elasticsearch Serviceとは

Amazon Elasticsearch ServiceとはElasticsearchを簡単にデプロイ、保護、実行する完全マネージド型サービスです。
Elasticsearchはオープンソースの検索エンジンですね。
これをAWS上で簡単に使えるようにしたものになります。

では早速使ってみましょう。

Amazon Elasticsearch Serviceを使ってみよう

ドメインの作成

こちらもサンプルのデータがあるのでこちらを参考にやっていきます。

まず、Amazon Elasticsearch Serviceのマネージドコンソール画面から新しいドメインの作成を押します。

まずはデプロイタイプを選択します。
今回は開発およびテストを選択します。
バージョンは最新バージョンにしておきます。

次にドメインの作成です。
Elasticsearch ドメイン名は任意の名前で大丈夫です。
私は、testdomainとしました。

インスタンスタイプはc5.large.elasticsearchでノードの数はデフォルトの1にします。

データストレージとマスターノードもそれぞれデフォルトの値で大丈夫です。

スナップショットの設定と任意の Elasticsearch クラスター設定もそのままで次へを押します。

次にアクセスとセキュリティの設定です。
ネットワーク構成はパブリックアクセスを選択します。

細かいアクセスコントロール – Open Distro for Elasticsearch を搭載の部分はマスターユーザーの作成を選択します。
マスターユーザー名とマスターパスワードは任意で大丈夫です。
ただし

マスターパスワードは、少なくとも 8 文字で、1 つの大文字、1 つの小文字、1 つの数字、および 1 つの特殊文字を含める必要があります。

となっておりますので注意してください。

Amazon Cognito 認証はそのままでアクセスポリシーはドメインへのオープンアクセスを許可を選択します。

暗号化もそのままで次へを押します。

最後に確認画面が出るので確認できたら確認を押します。

Amazon CloudSearchの時のドメインの作成より長かったですね…

確認を押すとこの画面になります。
こちらも10分ほどかかるので待ちましょう。

この画面になれば作成完了です。

データをアップロードする

サンプルのデータをアップロードします。
ここにあるようにコマンドを叩いてアップロードしてみてください。

master-userとmaster-user-passwordは先ほど設定したものを使用すれば大丈夫です。
domain-endpointは下の赤枠の値です。

これで準備完了です。

実際に検索してみる

では、実際に検索してみましょう。

KibanaのところのURLをクリックします。

下の画面に遷移しますので作った先ほど作ったマスターユーザー名とパスワードを入力してLog inを押します。

Kibanaは少なくとも1つのインデックスパターンが必要なのでそれを作成します。
下の画像の赤枠部分を押します。

今回はIndex patternにmoviesと入力しました。
入力したらNext stepを入力します。

あとはCreate index patternを押すとできます。

これでやっと検索できます。
検索バーにmarsと入力してEnterを押します。

こんな感じで検索ができます。

まとめ

Amazon CloudSearchとAmazon Elasticsearch Serviceを実際に触ってみました。
実際にデータをどこからかとってやってみた方がいいのかなと思ったのですが今回はサンプルデータを使用してみました。
こうやってみるだけでも流れがわかっていいですね。

作成したドメインを削除することもお忘れなく。

以上、濱岡でした!

【入門】AWS ConfigでAWSリソースの設定履歴を調査する

$
0
0

体重が増加傾向にあるCI部の柿﨑です。

AWS ConfigでAWSリソースの設定履歴を確認する方法について、記述します。
例として、AWS CloudTrail上で操作履歴を特定したい場合に、AWS Config上の「設定タイムライン」から追跡した方が操作履歴の特定が早くて確実なケースがあります。
また、AWSリソースの設定変更時、障害対応時の調査にも使えますので、AWS ConfigやAWS CloudTrailの設定はぜひとも有効化することを推奨します。

手順

1.AWS Configのコンソールからリソースを押下

2.リソースを指定して検索(今回はルートテーブルを対象とします。)

3.任意のリソースを選択

4.設定タイムラインを押下

5.AWS Configに記録されている設定履歴が表示されるため、任意の履歴を選択

6.選択した履歴の情報が表示されるため、「関係」「変更」「CloudTrail イベント」を確認

6-1.「関係」を確認
こちらでは選択したルートテーブルと関係のあるAWSリソースが表示されます。
特にAWSリソースの設定変更時にどのAWSリソースに対して影響を与えるか、などを特定するのに役立ちます。
以下の画像に表示されている例では、VPCとサブネットはルートテーブルに関連付けられており、ENIはルート情報に関連付けられています。

6-2.「変更」を確認
この設定タイムライン時点での変更内容が記録されています。
「開始」には設定変更前の情報が、「終了」には設定変更後の情報が記載されています。
それぞれ空白となっている箇所は設定が存在しないことを意味し、「開始」に設定が記載され、「終了」が空白となっている場合は設定が削除されています。
また、設定変更に伴う「関係」の情報も記録されており、本設定では新しくENI向けのルートを追加したため、ENIとの関係が発生したことを確認できます。

6-3.「CloudTrail イベント」を確認
本設定に関連するAWS CloudTrailの履歴を確認できます。
特定のAPI履歴を追跡する場合にAWSリソースが判明していれば、こちらから追跡をする方が早くて確実なケースがございます。
最後に「イベントの表示」を押下し、さらに内容を確認してみます。

7.AWS CloudTrail上での確認
以下画像のとおり、AWS Config上からAWS CloudTrailの「イベント履歴」を確認できました。

さいごに

AWS CloudTrailだけではAPI履歴をパッと確認することができても、どのような変更があったのかを確認することがやや困難です。
逆にどのような変更があったのかが判明していれば、AWS Config上から追跡することで関連するAPI履歴を迅速に特定することができます。
障害対応時は1秒でも惜しい場面があるかと思われますので、ぜひご活用いただければと思います♪

[Docker入門]Dockerとは:Dockerとコンテナの基本概念

$
0
0

はじめに

こんにちは。孔子の80代目子孫兼技術5課の孔です。最近夏になり、暑くて不眠症が悪化してきました。睡眠不足は肌に悪いですね。ツヤツヤ肌が数少ない取り柄なので、健康睡眠を意識していこうと思ってます。

最近Dockerの勉強が一段落し、そのアウトプットをします。いくつかの記事に分けて段階的に知識をアウトプットしていきたいと思います。以下のようなシリーズで記事を書いていきます。

  1. Dockerとは:Dockerとコンテナの基本概念
  2. さらに必要な基礎知識、レジストリとDockerfile、そしてビルド
  3. Dockerを使ってコンテナを触ってみよう:Dockerの使い方の基本
  4. Dockerのツールその1、Docker compose
  5. Dockerのツールその2、swarm

その1編目として、Dockerとコンテナの基本概念をこの記事では紹介していきます。今回の記事の構成は以下のようになります。

  1. Dockerとは何か
  2. イメージを知ろう
  3. レイヤーを知ろう

それでは始めましょう!Let’s dive!

Dockerとは何か

Dockerはコンテナ技術を使って簡単にアプリケーション環境をデプロイすることができるオープンプラットフォームです。コンテナと呼ばれるアプリケーションにあった環境をプロセスとして作成し、ホストOSに依存せずDockerが通訳者として入ることでOSに依存せず環境を構築することができます。以下Dockerの概念を図で表したものとなります。

図で確認できるように、DockerはホストOSとアプリケーション環境(コンテナ、図ではAppになっているもの)の間で、どのOSでもアプリケーションを環境の違いなく駆動できるような役割を果たします。Dockerをより理解するためによく比較されるのがVMとの違いについてです。VMはホストOS上に仮想環境を作り、全く違うOSがホストOS上にゲストOSとして存在しているかのおように見せる技術です。DockerはやっていることはVMと似ていますが、動く基盤も考え方も全く違いますので注意してください。

  • VM:ゲストOSがホストOS上に存在し、環境を制御するのはゲストOSであり、このゲストOSを構築するためのもの
  • Docker:ホストOS上にデーモンとして存在し、OSに依存せず環境を構築できるように中間者の役割を果たしているもの

Dockerが駆動するコンテナは実はOSの一つのプロセスにすぎない、と考えるともっとわかりやすいかと思います。Dockerを使ってhttpd環境を作成し、ホストOSでプロセスをみてみると以下のことを確認することができます。

kong@KongnoAir ~ % docker container run -d httpd
Unable to find image 'httpd:latest' locally
latest: Pulling from library/httpd
afb6ec6fdc1c: Pull complete 
5a6b409207a3: Pull complete 
41e5e22239e2: Pull complete 
9829f70a6a6b: Pull complete 
3cd774fea202: Pull complete 
Digest: sha256:db9c3bca36edb5d961d70f83b13e65e552641e00a7eb80bf435cbe9912afcb1f
Status: Downloaded newer image for httpd:latest
e29f06721a6e7593240fd73a62a429bb3dde7e63c27bb81679c6196ac5c53f99
kong@KongnoAir ~ % docker container ls
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
e29f06721a6e        httpd               "httpd-foreground"       4 seconds ago       Up 3 seconds        80/tcp              beautiful_swanson
kong@KongnoAir ~ % ps aux | grep httpd
kong             28353   0.0  0.0  4287740    732 s000  S+    5:34PM   0:00.01 grep httpd

コンテナで作成した環境はプロセスとしてホストOSが実行しています。VMだとゲストOSが存在し、ホストOSとはOSレベルで分離されるのでこのようにプロセスを確認することができません。これがコンテナとVMの違いです。

イメージを知ろう

Dockerのコンテナを作成するために必要なものがイメージと呼ばれるものです。Dockerはイメージと呼ばれるものからコンテナを作成していきます。それではイメージはどのようなものなのか、みてみましょう。

コンテナがどのような環境を作成するのか、その土台となるものがイメージです。先ほど’docker container run -d httpd’というコマンドは、httpdの環境となるコンテナを起動するための命令になります。ここでhttpdがイメージとなります。イメージの中にはhttpd環境を構築するためにどのようなOSをベースとして使うか、どのポートを開けるか、どのパッケージをインストールするかなどなどがビルドされており、コンテナをイメージから起動することができるようになります。

API-Driven DevOps: Spotlight on Docker | Nordic APIs |

こちらの図はイメージをレジストリ(次回の記事で説明)からダウンロードし、そのイメージからコンテナを作成する流れを図示したもののなります。簡単に、コンテナを作成するための土台となるものがイメージ、と覚えるといいかと思います。このイメージというものをもう少し掘り下げてみたい方は、次の「レイヤーとを知ろう」を読んでください。

レイヤーを知ろう

レイヤーとは、イメージをビルドするときにDockerが作成するキャッシュファイルとなります。このレイヤーを組み合わせることによって一つのイメージが作成されます。ちなみに、このイメージの上にさらに一つのレイヤーとして存在するのがコンテナとなります。Dockerの全てのレイヤーは統合されたファイルシステム上で管理されています。ファイルシステムから持ってきた同じレイヤーの組み合わせの上にさらに一つのレイヤーを追加するだけなので、コンテナは軽量で動き、素早くデプロイできます。具体的なイメージを掴めるために以下のシェル画面をみてください。

kong@KongnoAir ~ % docker image history httpd
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
d4e60c8eb27a        3 days ago          /bin/sh -c #(nop)  CMD ["httpd-foreground"]     0B                  
<missing>           3 days ago          /bin/sh -c #(nop)  EXPOSE 80                    0B                  
<missing>           3 days ago          /bin/sh -c #(nop) COPY file:c432ff61c4993ecd…   138B                
<missing>           3 days ago          /bin/sh -c #(nop)  STOPSIGNAL SIGWINCH          0B                  
<missing>           3 days ago          /bin/sh -c set -eux;   savedAptMark="$(apt-m…   60.9MB              
<missing>           3 days ago          /bin/sh -c #(nop)  ENV HTTPD_PATCHES=           0B                  
<missing>           3 days ago          /bin/sh -c #(nop)  ENV HTTPD_SHA256=a497652a…   0B                  
<missing>           3 days ago          /bin/sh -c #(nop)  ENV HTTPD_VERSION=2.4.43     0B                  
<missing>           3 days ago          /bin/sh -c set -eux;  apt-get update;  apt-g…   35.4MB              
<missing>           3 days ago          /bin/sh -c #(nop) WORKDIR /usr/local/apache2    0B                  
<missing>           3 days ago          /bin/sh -c mkdir -p "$HTTPD_PREFIX"  && chow…   0B                  
<missing>           3 days ago          /bin/sh -c #(nop)  ENV PATH=/usr/local/apach…   0B                  
<missing>           3 days ago          /bin/sh -c #(nop)  ENV HTTPD_PREFIX=/usr/loc…   0B                  
<missing>           4 days ago          /bin/sh -c #(nop)  CMD ["bash"]                 0B                  
<missing>           4 days ago          /bin/sh -c #(nop) ADD file:7780c81c33e6cc5b6…   69.2MB

‘docker image history httpd’は、指定したイメージ(httpd)のビルド履歴を確認するコマンドとなります。履歴をみてみるとhttpd環境がうまく動作するためのいろいろな処理をしていることがわかります。この中身については次回の記事でみていきます。

このように、イメージは複数のレイヤーの重なりとなります。このレイヤーは一つ一つSHAによってハッシュ値が付与され、同じことをやるレイヤーであれば違うイメージ同士でもハッシュ値を使って共有することができます。つまり、イメージは一つのスタックでなく、レイヤーの重なりである、と理解するといいかと思います。

まとめ

今回はDockerとは何か、イメージとは何か、そしてイメージの構成要素となるレイヤーとは何かについてみてみました。次回はレジストリとDockerfileについて、そしてDockerfileをビルドするために必要な知識をいくつかお伝えしたいと思います。それではお元気で😇!

【AWS超入門】初心者は必ずチェック!アクセス権限のきほん

$
0
0

こんにちは、技術1課の加藤です。
ただでさえ新型コロナウィルスの影響で在宅勤務な上、温度の乱高下でへばりそうな今日この頃。みなさま、どうぞご自愛くださいませ。

今回は、弊社YouTubeチャンネルにて最近アップロードを始めました「はじめてのAWS」シリーズの中から「AWS権限管理 – はじめの一歩」を取り上げまして、その内容をお伝えしていきます!

動画で見たいという方はこちらをどうぞ!

お伝えすること / しないこと

ここでは AWS 権限管理の基礎の基礎として、

  • AWS へアクセスするユーザーの種別やその使い分け
  • ユーザーの見分け方

についてお伝えしていきます。

具体的な手順や詳細なサービス仕様について語るものではないためご了承ください。
今回はあくまで、概念のお話です。

対象読者

ルートユーザーやIAMユーザーの話、と聞いてピンと来る方は読まなくて大丈夫です。

逆にピンとこないぞ、という方。
AWS を利用する上で絶対把握して欲しい内容になりますので必ず読んでください!

絶対覚えて欲しいベストプラクティス

このブログや動画を通して最も伝えたいことが以下の2つ。

  1. ルートユーザーは普段使いしない!
  2. 利用者ごとにIAMユーザーを払い出し、これを使ってAWSにアクセスする!

当たり前の人にとっては当たり前のことですが、意外と知らないという人も多いのがこの原則。
細かく説明していきます。

用語の確認

AWS の概念としてのユーザーと、利用する人間という意味でのユーザーがごっちゃになるとわかりにくいのでここからは

  • 概念:ユーザー
  • 人間:利用者

と区別してご説明していきます。

AWS へアクセスするユーザーの種別

すでにお話している通り、AWS へアクセスするユーザーには以下の2種類があります。

  • ルートユーザー
  • IAMユーザー

アカウントを作成した直後はルートユーザーのみが存在し、その後利用者が作成することで使えるようになるのが IAM ユーザーとなります。

ルートユーザー

ではまずルートユーザーから確認していきましょう。

ルートユーザーってどんなユーザー?

名前から想像がつく方もいるかもしれませんが、AWS に関する全権を持つユーザーのことです。
他のサービスでAdministratorや管理者、スーパーユーザーなどと呼ばれる概念に近しいものです。

全権を持っているので、ルートユーザーを使えば何でもできます。

あらゆるリソースの作成・削除。
アカウントのサインイン情報の変更やアカウント解約もこのユーザーで行います。

ルートユーザーを使う危険性

なんでもできるアカウントを使うのは運用上非常に楽ではあります。
それをみんなで使いまわせば、全員、必ずやりたいことができますからね。

とはいえセキュリティ観点で見るとこの状況は非常に危ないです。
例えば誰かが誤って認証情報を漏らしてしまったとしたとき。
被害は甚大です。

悪意のある人間が認証情報を受け取ってしまったら、
例えば高価なリソースを大量に作成して多額の請求を発生させたり、逆に存在するリソースを軒並み削除されてしまったり、
最悪サインイン情報の変更やアカウントの解約をされてしまえば、アカウントが利用できなくなる事態にもなりかねません。

ルートユーザーは普段使いしない

以上から、ベストプラクティスは「ルートユーザーは普段使いしない」となります。
使わなければ情報漏洩リスクを大きく減らすことができます。

加えて MFA の設定や強固なパスワードの設定などを徹底し、ルートユーザーが他人の手に渡ることがないよう細心の注意を払いましょう。

IAM ユーザー

次に IAM ユーザーの説明をしていきますが、これを理解するためにはまず IAM について知らないといけません。

IAM – Identity and Access Management

IAM は AWS の権限管理を一挙に担うサービスです。
これを使えば「誰が」「どのリソースに対する」「どんな操作」を行うことができるのかをきめ細かに設定管理することができます。
AWS を扱う上では必ず理解しておかなければいけない重要なサービスといえるでしょう。

IAMを使うと以下のような制御が簡単にできます。

  • 仮想サーバーの起動・停止はできるが、作成・削除はできない
  • Aさんはストレージの読み込みができるが、Bさんは読み書き両方できる
  • 特定のIPアドレス帯からのアクセスのみを許可する

IAM の4つの要素

IAM は主に 4つの要素で構成されます。

  • IAM ユーザー … AWS にアクセスするための要素
  • IAM グループ … ユーザーを束ねる要素
  • IAM ポリシー … 権限セット
  • IAM ロール … AWS サービスに権限を与える要素

つまり IAM ユーザーとは、
権限管理サービスである IAM の 1要素であり AWS にアクセスするためのもの、ということが言えます。

IAM ユーザーは利用者ごとひとつ

IAM ユーザーは与えたい権限と認証情報を設定することで作成ができます。
またどの IAM ユーザーがどのような操作を行なったのか、というログをとることが可能なため、利用者ごとにIAMユーザーを1つ作るのがベストプラクティスです。

それぞれの利用者に対し、必要な最低限の権限を割り当てたユーザーを発行し、それを使ってAWSへアクセスするようにしましょう。

ユーザーの見分け方

ルートユーザーとIAMユーザーは、そもそもサインイン画面から違います。
またサインイン後の画面でも違う部分がありますので、そちらで判別することもできます。

詳しい見分け方については動画を見ていただいた方がわかりやすいかと思いますので、以下を参考にしてみてください。

ルートユーザー、IAMユーザーの見分け方 | [はじめてのAWS] AWS権限管理 – はじめの一歩

まとめ

最後にもう一度ベストプラクティスを振り返ります。

  1. ルートユーザーは普段使いしない!
  2. 利用者ごとにIAMユーザーを払い出し、これを使ってAWSにアクセスする!

もしも普段ルートユーザーを使っていた! という方がいらっしゃいましたら、必ず、ルートユーザーの保護とIAMユーザーの作成を行い、安全にAWSを利用できるようにしましょう。

[Dokcer入門]リポジトリとDockerfile、そしてビルド

$
0
0

はじめに

こんにちは。孔子の80代目子孫兼技術5課の孔です。最近暑いなと思っていたら、昨日から雨が降っていて今日は朝からとても寒いですね。おかげさまで途中で起きることなくぐったり寝ることができました。

前回はDockerとは、イメージとは、そしてレイヤーとはどのようなものなのかをみてみました。こちらの知識はDockerの最も基本的な概念となりますが、Dockerを使うにあたってまだまだ必要な基礎知識があります。それが今回ご説明いたします、リポジトリとDockerfile、そしてビルドとなります。それでは、早速みていきましょう。Let’s get it!

リポジトリとは

前回の記事でコンテナのベースとなるイメージというものがどのようなものなのか説明しました。このイメージをどのように管理するのかを今からみていきます。前回の記事でhttpdをダウンロードしたこと、覚えてますでしょうか。こちらのものになります。

kong@KongnoAir ~ % docker container run -d httpd
Unable to find image 'httpd:latest' locally
latest: Pulling from library/httpd
afb6ec6fdc1c: Pull complete 
5a6b409207a3: Pull complete 
41e5e22239e2: Pull complete 
9829f70a6a6b: Pull complete 
3cd774fea202: Pull complete 
Digest: sha256:db9c3bca36edb5d961d70f83b13e65e552641e00a7eb80bf435cbe9912afcb1f
Status: Downloaded newer image for httpd:latest
e29f06721a6e7593240fd73a62a429bb3dde7e63c27bb81679c6196ac5c53f99

コンテナを起動するコマンドを入力したときに、その結果をみてください。まず2行目で”Unable to find image ‘httpd:latest’ locally”と言われてますね。Dockerはイメージをローカルに保存し、コンテナを起動する際にイメージがローカルにあるかどうかをまずチェックします。もしなかったらイメージをリポジトリにダウンロードしにいきます。それでは、このリポジトリというものは一体何でしょう?

リポジトリはイメージを保管しているサーバとなります。デフォルトではDockerhubが指定されています。Dockerhubに入り、httpdイメージを検索してみるとhttpdというイメージが一番上に出てくるのがわかります。コンテナを起動する際に指定したイメージがローカルになかった場合、リポジトリをみに行ってhttpdがあるかどうかを検索し、あったらダウンロードしてコンテナを起動する流れとなります。

API-Driven DevOps: Spotlight on Docker | Nordic APIs |

前回使用した図となりますが、こちらのレジストリの中にhubというものがありますね。いろいろなレジストリ上にイメージを保存し、そこからイメージをダウンロードしてコンテナを立ち上げるのが基本的なコンテナ構築の流れです。

デフォルトリポジトリ(Dockerhub)以外のリポジトリを指定するときにはイメージ名の前にurlを指定するだけです。AWSのECRのドキュメントに記載されているコマンドを持ってきました。このように、amazonlinux:latestというイメージをダウンロードする際にaws_account_id.dkr.ecr.us-west-2.amazonaws.com/というurlから持ってきて!という命令になります。(原本はコマンドがdocker pullになっていますが、こちらは任意でdocker image pullに変更しました。コマンドについては次回詳細に説明します)

docker image pull aws_account_id.dkr.ecr.us-west-2.amazonaws.com/amazonlinux:latest

リポジトリを簡単に要約しますと、イメージを蓄えておいて必要なときにダウンロードできる場所、と覚えると良いかと思います。

Dockerfileとは

イメージをリポジトリからダウンロードできることがわかった今、それではこのイメージってどうやって作るんだろうという疑問がそろそろ出てくるのではないかと思います。そのイメージを作成するために必要なものがDockerfileとなります。Dockerfileはイメージをビルドするときに、このイメージがどのようなものなのかを定義したものとなります。以下の例をみてください。

FROM debian:buster-slim

ENV NGINX_VERSION   1.17.10
ENV NJS_VERSION     0.3.9
ENV PKG_RELEASE     1~buster

<中略>

RUN ln -sf /dev/stdout /var/log/nginx/access.log \
    && ln -sf /dev/stderr /var/log/nginx/error.log

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

こちらはnginxのDockerfileの一部となります。解説すると

  • FROM:ベースイメージとしてどのOSイメージを使用するか(Debianを使用する)
  • ENV:環境変数を指定する
  • RUN:イメージをビルドする際に実行するコマンドを指定する
  • EXPOSE:どのポートを開けるか
  • CMD:コンテナを作成する際に実行するコマンドを指定する

となります。もっといろいろなDockerfileのコマンドを知りたい方はこちらのドキュメントをご覧ください。このように、Dockerfileではこのイメージがどのようなイメージとなるのか、その詳細を記入しているファイルだな、ということをイメージできればいいかと思います。

ビルド

Dockerfileを作成したら、ビルドをすることでイメージを作ることができます。以下のシェルをみてください。

kong@KongnoAir ~ % docker image build -t test:latest .
Sending build context to Docker daemon  6.499MB
Step 1/2 : FROM ubuntu
 ---> 1d622ef86b13
Step 2/2 : RUN apt-get update
 ---> Running in 29924a2ea92e
Get:1 http://security.ubuntu.com/ubuntu focal-security InRelease [107 kB]
<中略>
Fetched 13.8 MB in 8s (1659 kB/s)
Reading package lists...
Removing intermediate container 29924a2ea92e
 ---> 98d48c9e8359
Successfully built 98d48c9e8359
Successfully tagged test:latest

docker image buildは、Dockerfileをビルドするためのコマンドです。-t オプションはイメージの名前をつけるもので、今回はtestというイメージ名とlatestというタグを付けました。最後の点(.)は「現在のディレクトリにあるDockerfileという名前のファイル」を指定しています。こちらはもちろんパスやファイル名を指定することも可能です。

ビルドの内容をみてみると、ベースのubuntuイメージにapt-get upudateをしているだけのイメージとなります。Dockerfileのそれぞれの命令を見て、イメージを作っていきます。

追加で、こちらのシェル画面もみてください。

kong@KongnoAir code_local % docker image build -t test:latest .                                                                         ~/Documents/code_local
Sending build context to Docker daemon  6.499MB
Step 1/2 : FROM ubuntu
 ---> 1d622ef86b13
Step 2/2 : RUN apt-get update
 ---> Using cache
 ---> 98d48c9e8359
Successfully built 98d48c9e8359
Successfully tagged test:latest
kong@KongnoAir code_local % docker image build -t test2:latest .
Sending build context to Docker daemon  6.499MB
Step 1/2 : FROM ubuntu
 ---> 1d622ef86b13
Step 2/2 : RUN apt-get update
 ---> Using cache
 ---> 98d48c9e8359
Successfully built 98d48c9e8359
Successfully tagged test2:latest
kong@KongnoAir code_local % docker image ls
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
test2               latest              98d48c9e8359        2 minutes ago       95.5MB
test                latest              98d48c9e8359        2 minutes ago       95.5MB
httpd               latest              d4e60c8eb27a        4 days ago          166MB
ubuntu              latest              1d622ef86b13        3 weeks ago         73.9MB

もう一度同じ名前でビルドをしてみると、今回はStep2のところで”Using cache”と言われています。これが前回説明したレイヤーとなるものです。ビルドしたイメージはレイヤーの重なりであることを覚えていますでしょうか。一回ビルドを行っていたので、レイヤーをDockerデーモンが保持している状態となります。ですので次回もし同じレイヤーを使用するようなビルドがあったらレイヤーを共有してビルドを速度をあげています。イメージ名をtest2に変えた時も同様で、このようにレイヤーを共有することによってDockerはビルドの速度をあげることができています。

最後に

今回はリポジトリ、Dockerfile、そしてDockerfileのビルドまでみてみました。基本的な概念はこれで一通り触れることができたと思いますので、次回は重要なコマンドを一つずつ紹介し、今まで説明した内容をコマンドを使って実際やってみようと思っています。それではお楽しみに!

Viewing all 1210 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>