What's New Qiita

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

  • 投稿日：2020-02-04T22:41:42+09:00

AWS Amplify を日本語化してみた

はじめに

このページでは Amplify の初期画面で作成した認証画面を日本語化するための方法をまとめました

※ 翻訳するメッセージについては以下のページを参考にさせていただきました。
https://www.aruse.net/entry/2019/03/25/225802

開発環境

  • Windows 10
  • nodist(nodeのバージョン管理)
    • node 12.13.0
  • VSCode

Amplify で多言語化対応する

I18n で言語設定をしてみる

Amplify には I18n ライブラリが初めから用意されている。
そのためライブラリを import することで、多言語化対応することが可能ということがわかった。

【参考】
https://aws-amplify.github.io/docs/js/i18n

ということで、前回の投稿したソースコードを少し修正してみた。

main.js
import Amplify from "aws-amplify";
import { I18n } from "aws-amplify";
import aws_exports from "./aws-exports";

I18n.setLanguage("ja");
以下省略

これで日本語化完了したので、さあ実行してみましょう！

image.png
・・・世の中そんなに甘くなかったよ

sample で fr と書いているけれど、fr にしても変更しない・・・
ということは自分で何かしら定義しないといけないことがわかってきました。

自分自身の辞書を作成して設定する

リファレンスを読み進めると、以下の用なメソッドを見つける

image.png

どうやら必要な言語については自分で辞書を作成して設定する必要があるらしい

src/i18n/amplify/messages.js
export const messages = {
  ja: {
    "Back to Sign In": "サインイン画面に戻る",
    Confirm: "確認",
    "Confirm Sign Up": "サインアップの確認",
    "Confirmation Code": "確認コード",
    "Create Account": "新規登録",
    "Create a new account": "アカウントの新規登録",
    "Create account": "新規登録",
    Email: "メールアドレス",
    "Enter your code": "確認コードを入力してください",
    "Enter your password": "パスワードを入力してください",
    "Enter your username": "ユーザー名を入力してください",
    "Forget your password? ": "パスワードをお忘れの方 ",
    "Have an account? ": "アカウント登録済みの方 ",
    Hello: "こんにちは ",
    "Incorrect username or password": "ユーザー名またはパスワードが異なります",
    "Lost your code? ": "コードを紛失した方 ",
    "No account? ": "アカウント未登録の方 ",
    Password: "パスワード",
    "Phone Number": "電話番号",
    "Resend Code": "確認コードの再送",
    "Reset password": "パスワードのリセット",
    "Reset your password": "パスワードのリセット",
    "Send Code": "コードの送信",
    "Sign In": "サインイン",
    "Sign Out": "サインアウト",
    "Sign in": "サインイン",
    "Sign in to your account": "サインイン",
    "User does not exist": "ユーザーが存在しません",
    Username: "ユーザー名",
    "Username cannot be empty": "ユーザー名は必須入力です",
    "Username/client id combination not found.": "ユーザー名が見つかりません"
  }
};

※ フォーマットチェックをデフォルトのままで整形するとすごい悲惨な状態に・・・次までの課題とします
また上記メッセージについては冒頭のページを参考にさせていただきました。

main.js
import Amplify from "aws-amplify";
import { I18n } from "aws-amplify";
import { messages } from "./i18n/amplify/messages";
import aws_exports from "./aws-exports";

Amplify.configure(aws_exports);
I18n.putVocabularies(messages);
I18n.setLanguage("ja");
以下省略

辞書を設定して日本語の辞書を使用する処理を追加して起動するとエラーが発生しなかったので、ページにアクセスをしてみましょう

image.png

日本語化されていることが確認できました！
翻訳する文言が足りなかったりすると英語が表示されたので、画面の確認作業は必要になりそうですね。。。:sweat_smile:

パスワードリセットのリンク先のページやエラー文言も無事翻訳されていました

まとめ（翻訳するには）

Amplify では I18n というライブラリを用いて翻訳を行う
その際は以下の準備を行う必要がある

  • 使用する言語の辞書マップを作成する
  • どの言語を用いるか明確に定義する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T21:15:28+09:00

AWS ENI (Elastic Network Interface)について

ENI (Elastic Network Interface) とは

VPC上で実現する仮想ネットワークインタフェースで、物理的な環境におけるNIC（Network Interface Card）のこと。NICの場合は、サーバーに複数枚挿すことで、サーバーが担う複数の役割に応じてIPアドレスを複数持たせたり、異なるセグメント間で1台のサーバーを動作させたりすることができる。

ネットワークインターフェイスには以下の属性を含めることができる。

  • VPC の IPv4 アドレス範囲からのプライマリプライベート IPv4 アドレス
  • VPC の IPv4 アドレス範囲からの 1 つ以上のセカンダリプライベート IPv4 アドレス
  • プライベート IPv4 アドレスごとに 1 つの Elastic IP アドレス (IPv4)
  • 1つのパブリック IPv4 アドレス
  • 1 つ以上の IPv6 アドレス
  • 1 つ以上のセキュリティグループ
  • MAC アドレス

ENI の基本

  • インスタンスにアタッチしたり、インスタンスからデタッチしたり、別のインスタンスにアタッチしたりできる
  • VPC の各インスタンスには、プライマリネットワークインターフェイス (eth0) と呼ばれるデフォルトのネットワークインターフェイスが存在する

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T19:38:38+09:00

ALB を利用したサーバー負荷分散、可用性向上に向けた取り組み - Nextcloud 環境の構築を通じて AWS での環境構築を体験する④

「Nextcloud 環境の構築を通じて AWS での環境構築を体験する」 の第 4 回となります。
これまでの記事は下記からどうぞ。

はじめに

今回は、前回記事 で作成した環境構成のうち、Web サーバーを複数台構成することにより負荷分散ならびに可用性の向上を図ります。これを実現するために AWS のロードバランシングサービスを利用します。

また、可用性向上対策にあわせて、 現在シングル AZ となっている RDS をマルチ AZ に変更し、こちらも可用性向上を図ります。

今回構築する Nextcloud on AWS 環境

次のような構成となります。EC2 を 1 つ増設し、これを AWS のロードランシングサービスである ALB (Application Load Balancer) で負荷分散する形となります。

今回は、RDS のマルチ AZ 対応もあわせて行います。

image.png

# Web サービスでロードバランサを運用するといかにも「運用してるなぁ」という気がするのは私だけでしょうか w

今回追加で利用する AWS サービス

サービス名 役割
Elastic Load Balancing (ELB) スケーラブル、従量課金で利用できるマネージド型の負荷分散システム。今回は Application Load Balancer (ALB) というロードバランサーを利用します。
AWS Certificate Manager (ACM) パブリックとプライベートの TLS/SSL 証明書を簡単に作成、またマネージドな更新などの管理機能。

# AWS のロードバランサーのサービスの総称は "Elastic Load Balancing" ですが、その中で提供されるアプリケーションロードバランサーは "Application Load Balancer" です。

変更手順

Nextcloud サービスの一時停止

  1. Nextcloud の EC2 仮想サーバーに SSH 接続します。

  2. Nextcloud の cron を停止します。

    sudo mv /etc/cron.d/nextcloud-cron-php /etc/cron.d/.nextcloud-cron-php

  3. Nginx を停止します。

    sudo systemctl stop nginx

  4. Nginx の設定ファイルを変更します。今回の構成変更により、Web サーバー内で TLS/SSL の解決は行わず、前段のロードバランサーで解決するようにするため、 Web サーバーは HTTP のみで動作する形とします。

    sudo cp -pi /etc/nginx/conf.d/nextcloud.conf{,.orig}

sudo vi /etc/nginx/conf.d/nextcloud.conf
※以下のように一部行を削除と修正をします。
sudo diff /etc/nginx/conf.d/nextcloud.conf.orig /etc/nginx/conf.d/nextcloud.conf
10,23d9
<     # enforce https
<     return 301 https://$server_name:443$request_uri;
< }
< 
< server {
<     listen 443 ssl http2;
<     listen [::]:443 ssl http2;
<     server_name aws-nc.nextcloud.biz;
< 
<     # Use Mozilla's guidelines for SSL/TLS settings
<     # https://mozilla.github.io/server-side-tls/ssl-config-generator/
<     # NOTE: some settings below might be redundant
<     ssl_certificate /etc/letsencrypt/live/【Nextcloud を動かすサーバーの FQDN】/fullchain.pem;
<     ssl_certificate_key /etc/letsencrypt/live/【Nextcloud を動かすサーバーの FQDN】/privkey.pem;
65c51
<       return 301 $scheme://$host:$server_port/remote.php/dav;
---
>         return 301 https://【Nextcloud を動かすサーバーの FQDN】/remote.php/dav;
68c54
<       return 301 $scheme://$host:$server_port/remote.php/dav;
---
>         return 301 https://【Nextcloud を動かすサーバーの FQDN】/remote.php/dav;

  5. Nginx の設定ファイルを変更します。今回の構成変更により、ロードバランサがリバースプロキシとなるため、ロードバランサ経由でも問題なく Nextcloud にアクセスできるように設定を追加します。

    sudo cp -pi /var/www/html/nextcloud/config/config.php{,.orig3}

sudo vi /var/www/html/nextcloud/config/config.php
※以下のように一部行を追加をします。
sudo diff /var/www/html/nextcloud/config/config.php.orig3 /var/www/html/nextcloud/config/config.php
31a32,37
>   'trusted_proxies' => 
>   array (
>     0 => '【VPC のネットワークアドレス帯】',
>   ),
>   'overwriteprotocol' => 'https',
>   'overwritehost' => '【Nextcloud を動かすサーバーの FQDN】',

    # trusted_proxies は、構築している VPC のネットワークアドレス帯をすべて指定しておきます (デフォルト VPC だと 172.31.0.0/16)。これは、 ALB がマネージドサービスのため一意の IP アドレスで固定されないためです。
    ※もう少し厳しくするのであれば、下の設定例のようにパブリックサブネットのIPアドレス帯を 1 つずつ array に追加していく感じでしょうかね。

    (複数の IP アドレス帯を指定する場合の設定例)
  'trusted_proxies' => 
  array (
    0 => '192.168.100.0/24',
    1 => '192.168.102.0/24',
    2 => '192.168.104.0/24',
  ),

  6. EC2 サーバーをシャットダウンします。

    sudo shutdown -h now

RDS のマルチ AZ 対応

  1. AWS マネジメントコンソールにログインし、RDS サービスを選択します。「DB インスタンス」をクリックします。
    image.png

  2. 以前作成した Nextcloud のデータベースを選択し「変更」をクリックします。
    image.png

  3. 「インスタンスの仕様」の「マルチ AZ 配置」を「はい」に変更します。
    image.png

  4. さらに下にスクロールして「次へ」をクリックします。
    image.png

  5. 変更内容を確認し、変更スケジュールは「すぐに適用」を選択し「DB インスタンスの変更」をクリックします。
    image.png

  6. データベース一覧に戻るので、変更した DB インスタンスの DB 識別子をクリックします。
    image.png

  7. 「情報」が「変更中」となっている場合はもう少し待ちましょう。
    image.png

  8. 「情報」が「利用可能」となったら変更完了です。
    image.png

EC2 サーバーの追加

作成済みの EC2 の Web サーバーを複製して同じサーバーをもう 1 つ追加作成します。

  1. AWS マネジメントコンソールから EC2 サービスを選択します。「インスタンス」をクリックします。
    image.png

  2. EC2 のマシンイメージ (Amazon Machine Image : AMI) を作成していきます。Nextcloud の EC2 インスタンスを選択し、「アクション」－「イメージ」－「イメージの作成」の順にクリックします。
    image.png

  3. AMI イメージ名、イメージの説明を適当に設定して「イメージの作成」をクリックします。
    image.png

  4. マシンイメージの作成が開始されます。「保留中のイメージ xxxx の表示」のリンクをクリックします。
    image.png

  5. ステータスが「available」となっていたらマシンイメージの作成が完了しています。引き続きこのマシンイメージで EC2 インスタンスの複製を作成していきます。「起動」をクリックします。
    image.png

  6. ここ以降は、前回の EC2 インスタンスの作成と要領は同じです。ただし、サーバーが 2 つに増えるので、インスタンスタイプは前回作成のものより 1 ランク下げてみます (前回: t3.medium → 今回: t3.small)。インスタンスタイプを選択して「次のステップ: インスタンスの詳細の設定」をクリックします。
    image.png

  7. 「インスタンスの詳細の設定」では、「サブネット」を、前回作成した EC2 インスタンスとは異なるアベイラビリティゾーン (AZ) を選択します。これにより、AZ、すなわち AWS のデータセンター機能停止レベルの障害があってもサービス継続できるようにします。その他前回と同様に設定をして「次のステップ: ストレージの追加」をクリックします。
    image.png

  8. 「ストレージの追加」では特に変更はありません。そのまま「次のステップ: タグの追加」をクリックします。
    image.png

  9. 「タグの追加」では、前回同様に Name タグを追加します。前回の EC2 インスタンスと区別がつくように値を設定します。引き続き「次のステップ: セキュリティグループの設定」をクリックします。
    image.png

  10. 「セキュリティグループの設定」では、前回 EC2 インスタンスを作成した際に設定したセキュリティグループを選択し、「確認と作成」をクリックします。
    image.png

  11. これまで設定した内容を確認し、「起動」をクリックします。
    image.png

  12. SSH で使用するキーペアは、前回 EC2 インスタンスを作成したサイト同じものを選択しておくと後で管理しやすいと思います。キーペアの選択をして「インスタンスの作成」をクリックします。
    image.png

  13. EC2 インスタンスの作成が開始されます。「i-xxxx」のリンクをクリックします。
    image.png

  14. 「インスタンスの状態」が「running」、「ステータスチェック」が「2/2 のチェックに合格しました」となったら作成完了です。「search : i-xxxx」の右にある「×」をクリックします。
    image.png

  15. 引き続き、一時停止している EC2 インスタンスを起動しますが、起動前にインスタンスタイプを今回作成したものにそろえておきます。「アクション」－「インスタンスの設定」－「インスタンスタイプの変更」の順にクリックします。
    image.png

  16. インスタンスタイプを選択して「適用」をクリックします。
    image.png

  17. 設定変更したインスタンスを起動します。「アクション」－「インスタンスの状態」－「開始」の順にクリックします。
    image.png

  18. 「開始する」をクリックして起動を開始します。
    image.png

ロードバランサーの追加

引き続き今回のメイン、ロードバランサーの設定です。

  1. AWS マネジメントコンソールから EC2 サービスを選択します。左ペインをスクロールして「ロードバランサー」をクリックします。
    image.png

  2. 「ロードバランサーの作成」をクリックします。
    image.png

  3. 「Application Load Balancer」の「作成」をクリックします。
    image.png

  4. 以下のとおりロードバランサーの設定をしていきます。すべて設定したら「次の手順: セキュリティ設定の構成」をクリックします。

    項目 内容
    名前 ロードバランサーの名前
    スキーム インターネット向け
    ロードバランサーのプロトコル HTTPS (セキュア HTTP)
    VPC Nextcloud を構築している VPC を選択
    アベイラビリティゾーン 選択できる全てのアベイラビリティゾーンにチェックし、サブネットは、インターネット外部と通信できるサブネット(パブリックサブネット)を選択
    タグ "Name"キーとしてロードバランサーの識別名を設定

    image.png

  5. 「セキュリティ設定の構成」ではすべてデフォルトで OK です。ロードバランサーに設定する TLS/SSL 証明書は、ACM が発行する証明書を利用します。「次の手順: セキュリティグループの設定」をクリックします。
    image.png

  6. 「セキュリティグループの設定」では「新しいセキュリティグループを作成する」を選択します。その他はデフォルトで OK です。「次の手順: ルーティングの設定」をクリックします。
    image.png

  7. 「ルーティングの設定」は「ターゲットグループ」の「名前」にターゲットグループの名称を設定します。その他はデフォルトで OK です。「次の手順: ターゲットの登録」をクリックします。
    image.png

  8. 「ターゲットの登録」では、ALB でロードバランシングする EC2 インスタンスを登録します。画面下のインスタンス一覧から先に準備した Nextcloud の EC2 インスタンス 2 つをチェックし「登録済みに追加」をクリックします。そうすると「登録済みターゲット」にこれらのインスタンスが追加されます。追加したら「次の手順: 確認」をクリックします。
    image.png

  9. これまで設定した内容を確認して「作成」をクリックします。
    image.png

  10. ロードバランサーの作成が開始されます。「閉じる」をクリックします。
    image.png

  11. 状態が「provisioning」となっていたらロードバランサーを作成中です。しばらくお待ちください。
    image.png

  12. 状態が「active」となったら設定完了です。Nextcloud のドメイン (FQDN) はこのロードバランサーのサービスの DNS 名で解決するようになるので、DNS 名を記録しておきます。
    image.png

TLS/SSL 証明書の作成

ALB に設定する TLS/SSL 証明書を作成します。今回作成する証明書はAWS 自社認証局による「ドメイン認証 (DV)」のタイプとなります (これまで Web サーバーで設定していた Let's Encrypt の証明書も「ドメイン認証 (DV)」タイプです)。

「組織認証 (OV)」や「拡張認証(より厳格な組織認証) (EV)」の証明書は、別途取得したうえでインポートする必要があります。

  1. AWS マネジメントコンソールから Certificate Manager サービスを選択します。「証明書のリクエスト」をクリックします。
    image.png

  2. 「証明書のリクエスト」をクリックします。
    image.png

  3. 「ドメイン名」には Nextcloud を動かすサーバーの FQDN を設定して「次へ」をクリックします。
    image.png

  4. 「検証方法の選択」では「 DNS の検証」を選択して「次へ」をクリックします。
    image.png

  5. 作成する証明書にタグを付与します。 "Name" タグで名称を追加するなど行い、「確認」をクリックします。
    image.png

  6. 設定内容を確認して「確定とリクエスト」をクリックします。
    image.png

  7. 作成が開始されますが、証明書を作成するにあたって検証が必要です。対象ドメインの左にある三角マークをクリックすると、検証に必要となる DNS に追加登録する CNAME の情報が表示されます。以下の情報を DNS サーバー (もしくは Route 53 )に登録します。終わったら「続行」をクリックします。

    名前 タイプ 値
    【Nextcloud を動かすサーバーの FQDN名】 CNAME 作成した ALB の DNS 名
    (検証に必要な CNAME の名前) CNAME (検証に必要な CNAME の値)

    image.png
    以下は Route 53 での登録例です。
    image.png

  8. 対象ドメインの状況が「発行済み」となったら検証を含めて作成完了となります。これを先に作成した ALB に適用します。
    image.png

ALB に TLS/SSL 証明書を適用

  1. AWS マネジメントコンソールから EC2 サービスを選択します。左ペインをスクロールして「ロードバランサー」をクリックします。作成したロードバランサーを選択し、「リスナー」タブをクリック、「証明書の表示/編集」をクリックします
    image.png

  2. 「証明書」の右にある丸囲いの「＋」をクリック、 ACM で作成した証明書をチェックして「追加」ボタンをクリックします。
    image.png

  3. 「証明書は正常に追加されました」と表示されたら適用完了です。
    image.png

動作確認①

ここでいったん動作確認します。 "https://【Nextcloud を動かすサーバーの FQDN名】/" で Nextcloud にアクセス、ログイン/ログアウト、ファイルのアップロード/ダウンロードを試して問題ないことを確認します。

HTTP → HTTPS リダイレクト設定

前回までの環境では、 Nginx の設定で HTTP → HTTPS のリダイレクト設定が入っておりましたが、今回 Nginx では HTTP アクセスのみの設定となったため、ロードバランサーにて HTTP → HTTPS のリダイレクト設定を行う必要があります。
# Nginx 側で設定するやり方もありますがこちらのほうが簡単で分かりやすいです。

  1. AWS マネジメントコンソールから EC2 サービスを選択します。左ペインをスクロールして「ロードバランサー」をクリックします。作成したロードバランサーを選択し、「リスナー」タブをクリック、「リスナーの追加」をクリックします
    image.png

  2. 「プロトコル:ポート」はデフォルトで「HTTP : 80」が設定されます。「アクションの追加」－「リダイレクト先」の順にクリックします。
    image.png

  3. リダイレクト先として「HTTPS : 443」を設定します。あとはデフォルトで OK です。設定できたら「保存」をクリックします。
    image.png

  4. 「ポート 80 でリスナーが正常に作成されました」が表示されたのを確認して左上の「 < 」をクリックします。
    image.png

  5. 追加された「HTTP : 80」のリスナーに警告マークがつくのでクリックしてみます。
    image.png

  6. ロードバランサーに設定されているセキュリティグループで HTTP : 80 ポートの通信が許可されていないとのメッセージが表示されるのでこれを追加していきます。橙色で表示されているセキュリティグループ名のリンクをクリックします。
    image.png

  7. 「インバウンド」タブをクリックし「編集」をクリックします。
    image.png

  8. 「ルールの追加」をクリックし、タイプ「HTTP」のルールを追加して「保存」をクリックします。
    image.png

  9. HTTP のルールが追加されたことを確認します。
    image.png

動作確認②

HTTP → HTTPS リダイレクトが正しく動作するかを確認します。 "http://【Nextcloud を動かすサーバーの FQDN名】/" でアクセスすると "https://【Nextcloud を動かすサーバーの FQDN名】/" にリダイレクトされることを確認します。

動作確認③

EC2 インスタンスが 1 つダウンしても引き続きサービスが継続されることを確認してみます。

  1. EC2 サービスでインスタンスの一覧を表示します。今回は "Nextcloud-test-01" の EC2 インスタンスを停止してみます。「アクション」－「インスタンスの状態」－「停止」の順にクリックします。
    image.png

  2. 「停止する」をクリックします。
    image.png

  3. シャットダウン処理中です。処理が完了したら左ペインを下にスクロールして「ターゲットグループ」をクリックします。
    image.png

  4. ALB 作成の際に設定したターゲットグループを選択し、「ターゲット」タブをクリックします。 停止した "Nextcloud-test-01" サーバーが停止していることが表示されています。
    image.png

  5. この状態でサーバーは 1 基で運用されています。 Nextcloud にアクセスし、問題なく利用できることを確認します。

  6. 停止した EC2 インスタンスを再度起動します。 EC2 サービスでインスタンスの一覧を表示し、「アクション」－「インスタンスの状態」－「開始」の順にクリックします。
    image.png

  7. 「開始する」をクリックします。
    image.png

  8. EC2 起動処理中です。起動したら左ペインの「ターゲットグループ」をクリックします。
    image.png

  9. 起動した EC2 インスタンスが ALB のヘルスチェックに合格していることが確認できます。
    image.png

Cron の復活

  1. Nextcloud の EC2 仮想サーバーのうちの 1 つに SSH 接続します。

  2. Nextcloud の cron を復活します。

    sudo mv /etc/cron.d/.nextcloud-cron-php /etc/cron.d/nextcloud-cron-php

★両方のサーバーの Cron を復活させると、Cron が二重起動してしまいますので、片方のみ復活させてください

お疲れさまでした！　これですべての設定が完了です。

あとがき

ELB サービスについては、今回は利用しなかった Classic Load Balancer (CLB) を軽くお試し程度で 1 度構築したことある程度、ACM は CloudFront を利用したサービスで数度設定したことある程度で、今回のようにしっかりしたシステムで設定するのは初体験、うまく設定できるか不安でしたが、Nginx の設定変更以外はあまり迷わずに設定から動作まで実現することができました。
この状態で、前回よりもはるかに可用性の高い構成となっております。

現在の状態では Web サーバーを複数に分散したため、サーバーのログがそれぞれに分散してしまい、運用していくにはとても管理しづらい状況となっております。次回はこれらを集約し管理しやすくする設定を行ったりしていきます。

# 画面キャプチャでの説明は流れが把握しやすい反面、記事書くのは結構大変・・・AWS CLI とか CloudFormation のほうが楽かも。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T18:30:39+09:00

AWS Lake Formationの概要を図と用語で整理する

AWS Lake Formationをざっくりと理解するために基本的な概念とコンポーネントを、図と用語で整理してみます。

AWS Lake Formationとは？

  • AWSでデータレイクを構築・運用するためのマネージドサービス
    • 実体は、ほぼAWSの各種サービスをラップしたもの(Glue, IAM, S3, etc..)
    • データレイク専用にアクセス制御を行うために、IAMとは別に独自の権限管理機構を持つ
  • 実データも保持しセキュリティ向上と権限管理が簡単に行えるAWS Glueという印象
    • IAMやGlueを個別に駆使してデータレイクを構築・運用するよりデータレイクに特化していて扱いやすい

ざっくりした概念図

図にするとかなりシンプル。
image.png

備考

用語

AWS Lake Formationにおける各用語の定義。

用語 意味
データレイク(Data Lake) Lake Formationのデータカタログの実体としてS3に保管されたデータ。構造化データ、非構造化データのどちらも格納する
データアクセス(Data Access) Lake Formation（以後LF）において、データへのアクセス権限を管理する。実体はIAM
ブループリント(Blueprint) データレイクにデータを簡単に格納するためのテンプレート。ブループリントからワークフローを作成できる。
ワークフロー(Workflow) 関連ジョブの入れ物。ブループリントから生成される。実体はAWS Glueのクローラーとトリガー。Glueの面倒なあれこれをラップしている
データカタログ(Data Catalog) メタデータストア。Apache Hiveのようにメタデータでデータを管理。実体はそのままGlueのデータカタログ。1AWSアカウント、1リージョンに1つだけ作成できる
Underlying Data データカタログのテーブルが参照する元データ
プリンシパル(Principal) そのままIAMのプリンシパル
データレイク管理者(Data Lake Administrator) Lake Formation管理下にあるリソースの全権限を付与されたプリンシパル。LFを開始した際に最初に作られるユーザ。データレイク専用の管理者としてIAMの権限管理機能とは別に定義されており、IAMのAdministratorAccessを持っていても自動的にはデータレイク管理者にはならない(自分で自分を指定することは可能)。※詳細image.png

メモ

  • LFはGlueとデータカタログを共有する
  • Glueにできないことはできない
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T17:56:34+09:00

Amazon Transcribeでmedia formatが一致しないと言われる

AWSの文字起こしサービスであるTranscribeが日本語対応したので使い始めたが、下記のような「media formatが指定したのと違うよー」と言われて困った。

Failure reason
The media format that you specified doesn't match the detected media format. Check the media format and try your request again.

拡張子を変えたり、ffmpegでメディア情報を確認したりした結果、どうやらAmazon Transcribeでジョブをコピーすると、前に指定したメディアのメディア情報が引き継がれるらしいことが判明。

私の場合では、下図のように「Input file format」がwavを入れても「mp4」から変わらずでした。

スクリーンショット 2020-02-03 14.25.42.png

解決策は単純でコピーせずに別のジョブとして作り直せばOKでした。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T17:40:14+09:00

Terraform で特定のキュー（AmazonSQS）にしかアクセスできないポリシーを作成する

特定のキュー（AmazonSQS）にしかアクセスできないポリシーを Terraform で作成したメモです。

$ aws sqs get-queue-url --queue-name accessible-queue
{
    "QueueUrl": "https://ap-northeast-1.queue.amazonaws.com/${AccountID}/accessible-queue"
}
$ aws sqs get-queue-url --queue-name inaccessible-queue
An error occurred (AWS.SimpleQueueService.NonExistentQueue) when calling the GetQueueUrl operation: The specified queue does not exist or you do not have access to it.
main.tf
########################
## AWS Provider
########################
provider "aws" {
  access_key = local.access_key
  secret_key = local.secret_key
  region     = "ap-northeast-1"
}

##############################################
# SQS
##############################################
resource "aws_sqs_queue" "accessible_queue" {
  name = "accessible-queue"
}

resource "aws_sqs_queue" "inaccessible_queue" {
  name = "inaccessible-queue"
}

##############################################
# IAM User
##############################################
resource "aws_iam_user" "user" {
  name = "user"
}

##############################################
# IAM Policy
##############################################
resource "aws_iam_policy" "policy" {
  name   = "sqs-policy"
  policy = data.aws_iam_policy_document.policy_document.json
}

data "aws_iam_policy_document" "policy_document" {
  statement {
    sid = "Sid"

    actions = [
      "sqs:*",
    ]

    resources = [
      "${aws_sqs_queue.accessible_queue.arn}",
    ]
  }
}

resource "aws_iam_user_policy_attachment" "policy_attachment" {
  user       = aws_iam_user.user.name
  policy_arn = aws_iam_policy.policy.arn
}
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T17:18:27+09:00

AWSのRDSからdumpをとる方法

やりたいこと

ローカルのデータベースを本番のもので置き換えて動作検証がしたい。
そのためにRDSで作成している本番DBからdumpをとりたい！

やりかた

本番DBとローカルでsshトンネルを開通させる→dumpをとるコマンドを実行。

ポートフォワーディング(トンネル開通)とは？

https://www.clear-code.com/blog/2014/9/12.html
今回はローカルのポートから踏み台サーバーを経由してDBに接続する。

実行コマンド

ポートフォワーディング

必要な情報の取得方法は後述します。

ssh -N (実行ユーザーのuser name)@踏み台のIPアドレス -L ローカルのポート番号:DBのエンドポイント:DBのポート番号

必要によって以下のオプションを指定
-i: 秘密鍵の指定
-f: バックグラウンドで実行

DBのエンドポイント・ポート番号

Screen Shot 2020-02-04 at 17.01.15.png

RDS→Databases→該当DBの Endpoint name と Port をコピペ

踏み台のIPアドレス

EC2→Instances→該当インスタンスをチェックしたときに下に出てくる

Screen Shot 2020-02-04 at 17.11.35.png

このタブ内にある IPv4 Public IP をコピペ

ローカルのポート番号

現在使っていない番号だったら何でもOK。例えば今回は既に 3316 を使っていたので 3317 にした。

dumpをとるコマンド

これでコンソールからコマンドを打ってdumpが取れる状態になったので、以下でdumpをとる。

mysqldump -u <ユーザー名> -p -h 127.0.0.1 -P 3317 <DB名> > 20200204.dump

パスワードを求められるので入力。このユーザー名とパスワードはRDSのDBのもの。
mysqlの場合は localhost ではなく 127.0.0.1 とする必要があります。
これでdumpが取れました！?

補足

mysqldump: Couldn't execute 'SELECT COLUMN_NAME,
こんな感じで怒られる場合は、dumpのコマンドに --skip-column-statistics オプションを追加して以下のようにして下さい。

mysqldump --skip-column-statistics -u <ユーザー名> -p -h 127.0.0.1 -P 3317 <DB名> > 20200204.dump
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T16:17:07+09:00

AWS EC2 Amazon Linux 2 + Docker + Jenkins

概要

AWSのEC2(Amazon Linux2)でDockerでJenkins環境を構築する

Dockerのインストール

$ sudo yum install -y docker
$ sudo service docker start

自動起動を有効にする

$ sudo systemctl enable docker

docker imageのダウンロード

$ sudo docker pull jenkins/jenkins:lts

docker imageの起動

$ sudo docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins:lts

初期パスワード

先ほどのコマンド実行すると↓みたいなのが出力されるのでメモしておく

*************************************************************
*************************************************************
*************************************************************

Jenkins initial setup is required. An admin user has been created and a password generated.
Please use the following password to proceed to installation:

{パスワードがここに表示される}

This may also be found at: /var/jenkins_home/secrets/initialAdminPassword

*************************************************************
*************************************************************
*************************************************************

ブラウザアクセス

http://{IP}:8080/

image.png

ログイン

Administrator passwordに先ほどメモっといたパスワードを入力すれば完了

image.png

以降の作業は参考資料を見てもらえればと思います。

おわり

参考資料

Amazon Linux2にDockerをインストールする

Jenkinsをdocker上に構築

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T11:57:07+09:00

Amazon Linux から Amazon Linux 2 への移行中 xpath ではまった話

Amazon Linux AMI (2018.03) のサポート期間が2020年12月31日まで延びましたが、目下、過去の遺物を Amazon Linux 2 へ移行しています。
これはそんな中起きた問題で、結論は単純にxpathの演算子の優先順位を勘違いしていたという話です。
自分だけの勘違いではなく、まわりにも何人かいたので、もしかしたら有用かなと思って書きました。

皆さんは、このhtmlの2番目のh3のテキスト "Fuga" をxpathで取りたいときにどう書くでしょうか。

test.html
<!DOCTYPE html>
<html>
    <div>
        <h3>Hoge</h3>
        <h3>Fuga</h3>
        <h3>Gero</h3>
    </div>
    <div>
        <h3>Foo</h3>
        <h3>Bar</h3>
        <h3>Baz</h3>
    </div>
</html>

私とそのまわりの何人かは何の違和感もなくこう '//h3[2]/text()' 書いていました。

scraping.rb
require 'nokogiri'

doc = Nokogiri::HTML(open('test.html'))
p doc.xpath('//h3[2]/text()')

これは Amazon Linuxで yum パッケージの ruby2.0 と nokogiri だとこういう結果になります(これが古すぎるというのは置いといて)。

$ ruby scraping.rb
[#<Nokogiri::XML::Text:0x1160c78 "Fuga">]

そして、Amazon Linux 2 に移行すると、rubyは amazon-linux-extras の ruby2.4、nokogiri は gem で入れることになり、結果はこうなります。

$ ruby scraping.rb
[#<Nokogiri::XML::Text:0x2aea55368304 "Fuga">, #<Nokogiri::XML::Text:0x2aea55368160 "Bar">]

! !
異なる結果になってしまうのでした。これになかなか気づけずはまっていました。

理由

libxml2 の 2.9.2 でこういった修正が入っています。

Fix XPath '//' optimization with predicates (Nick Wellnhofer),

xpath の仕様では、 [] 演算子 は // よりも優先度が高いので、 //h3[2]/text() と書くと h3[2] の方に先にバインドされてしまうんですね。上で期待する操作をするときは (//h3)[2]/text() こう書くのが正でした。

libxml2 のバージョン 2.9.1 までここが間違っていて、Amazon Linux の yum リポジトリの libxml2 が 2.9.1 だったので、これまでうまく動いてしまっていたということです。

ちなみに

  • Amazon Linux でも gem で nokogiri をインストールしていれば回避できていました
  • Amazon Linux 2 でも yum の libxml2 は 2.9.1 なので、 xmllint なんかは間違ったままです
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T10:42:33+09:00

AWS Route53で無停止サブドメイン委任（すでにサブドメイン以下にCNAME等のレコードが存在するケース）

免責: DNSの専門家ではないので、よりよい方法があればぜひ教えてください！

背景

親ドメイン（例: hiroga.cc）のHosted Zone内でサブドメイン（例: sub.hiroga.cc）に関するレコードを管理していましたが、Hosted Zone内の見通しが悪くなってしまったので、サブドメインを分割します。
すでにレコードがあるケースの手順が調べても見当たらなかったため、備忘録とします。

手順

  1. サブドメイン用のHosted Zoneの作成
  2. サブドメイン用のHosted Zone内へ、親ドメインのHosted Zone内のレコードをコピー
  3. サブドメインのHosted Zoneに対するNSレコードの作成
  4. 親ドメインのHosted ZoneのNSレコードのTTLが過ぎるまで待つ。
  5. 親ドメインのHosted Zone内の、2.でサブドメイン側にコピーしたレコードの削除

注意点

  • 手順2.の段階で親ドメイン内のレコードを削除してはいけません。名前解決ができない時間が発生しますし、最悪悪意ある第三者が同様のレコードを公開するリスクがあると思われます。
  • 手順3.が完了した段階で疎通チェックをします。
dig NS sub.hiroga.cc   # サブドメイン側Hosted Zoneに対応するレコードが表示されること
dig CNAME some-web.sub.hiroga.cc   # AUTHORITY SECTIONがサブドメイン側Hosted ZoneのNSレコードの値であること

参考資料:

クラスメソッド - Route 53でサブドメインを別のHosted Zoneに権限委譲する

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T08:47:11+09:00

AWS Route53でサブドメインを取得し、SESで使用する

参考記事

https://qiita.com/tanakaworld/items/94f1ba66801100f6a44f

Route53でサブドメインの取得

Route53レコードセットの作成

  • 名前:適当な値を入力
  • タイプ:Aを選択
  • 値:192.168.0.1と192.168.0.2(環境に合わせてください)を入力し、レコードセットの保存を選択

SES設定

  • Identity Management => Domains を選択

  • Verify a New Domain を選択

  • Generate DKIM Settingsにチェックを入れる。

  • Domain:先ほど作成したサブドメインの値を入力

  • Verify This Domain を選択

  • Use Route 53を選択

  • Create Record Setsを選択

しばらく待ってから

  • Identity Management => Domains を選択
  • サブドメインを選択
  • Verification Status、DKIM Status、Enabled for SendingがYesやverifiedになっていることを確認

ステータスが正常なことを確認後

  • Send Test Emailを選択
  • 値をそれぞれ入力し、Send Test Emailを選択
  • メールが届くこと。迷惑メール判定されないことを確認。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T02:19:30+09:00

Cloudwatchのチュートリアルを読み解く

はじめに

DVAの試験範囲でもあるということで、今日はCloudwatchのチュートリアルをやってみました。

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/PublishMetrics.html

用語の解説

Cloudwatchを語る上で覚えておく必要のある用語をまとめます。

  • データポイント :

    • 個々のデータ（CPU使用率で言うと10%、20%のような具体的な値）

  • メトリクス :

    • データポイントを時系列順にまとめたセット

  • ネームスペース（名前空間） :

    • 発行されたメトリクスを格納するコンテナ（論理的な入れ物）
    • 任意の名前に設定可能（デフォルトのネームスペースは無し）
    • ただしAWSサービスのメトリクスではAWS/のネームスペースが使用される（例：AWS/EC2）

  • ディメンション :

    • メトリクスを一意に識別する名前と値のペア

ネームスペースとディメンションの使い分けがいつも混同するのですが、一番大きな枠がネームスペースで、その中から「どのサーバ（サービス）」を抽出するための検索ワードがディメンション、という理解です（ざっくり過ぎて間違っているかもしれませんが）

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html

※Blackbeltの資料のイメージ図がわかりやすいです。
cloudwatchimage.png

1.データ構成定義

※手順ではないので省略

2.CloudWatch にメトリクスを追加

AWS CLIのput-metric-dataコマンドを使用し、Cloudwatchに向けてデータポイントを発行します。
今回はメトリック名をRequestLatency、ネームスペース名をGetStartedと定義しています。

 aws cloudwatch put-metric-data --metric-name RequestLatency --namespace GetStarted \
 --timestamp 2016-10-14T20:30:00Z --value 87 --unit Milliseconds
 aws cloudwatch put-metric-data --metric-name RequestLatency --namespace GetStarted \
 --timestamp 2016-10-14T20:30:00Z --value 51 --unit Milliseconds
 aws cloudwatch put-metric-data --metric-name RequestLatency --namespace GetStarted \
 --timestamp 2016-10-14T20:30:00Z --value 125 --unit Milliseconds
 aws cloudwatch put-metric-data --metric-name RequestLatency --namespace GetStarted \
 --timestamp 2016-10-14T20:30:00Z --value 235 --unit Milliseconds

aws cloudwatch put-metric-data --metric-name RequestLatency --namespace GetStarted \
--timestamp 2016-10-14T21:30:00Z --statistic-values Sum=577,Minimum=65,Maximum=189,SampleCount=5 --unit Milliseconds

aws cloudwatch put-metric-data --metric-name RequestLatency --namespace GetStarted \
--statistic-values Sum=806,Minimum=47,Maximum=328,SampleCount=6 --unit Milliseconds

補足

Cloudwatchは2週間前までのデータしか参照できないようで、チュートリアルのコマンドをそのまま実行するとエラーになります。

An error occurred (InvalidParameterValue) when calling the PutMetricData operation: The parameter MetricData.member.1.Timestamp must specify a time within the past two weeks.

また、このチュートリアルは3つ目が現在時刻であることを想定しているようなので、1つ目、2つ目のタイムスタンプを「現在時刻-2時間（1時間）」で発行するか、3つ目に--timestampオプションを追加して実行しましょう。

--metric-name

  • 書式 : --metric-name (value)

発行するメトリクスの名前。

--namespace

  • 書式 : --namespace (value)

メトリクスのネームスペース名。

--timestamp

  • 書式 : --timestamp (value)

メトリクスに使用されるタイムスタンプ。
（タイムスタンプはISO 8601 UTC形式（2016-10-03T23：00：00Zなど）で指定）

指定しない場合、デフォルト値はメトリクスデータが受信された時間。

--value

  • 書式 : --value (value)

メトリクスの値。

--unit

  • 書式 : --unit (value)

メトリクスの単位。

3.CloudWatchから統計を取得

2で発行したメトリクスデータの統計を取得します。

aws cloudwatch get-metric-statistics --namespace GetStarted --metric-name RequestLatency --statistics Average \
--start-time 2016-10-14T00:00:00Z --end-time 2016-10-15T00:00:00Z --period 60

--start-time / --end-time

  • 書式 : --start-time (value) / --end-time (value)

集計するデータポイントの開始時間と終了時間。

--period

  • 書式 : --period (value)

集計時のデータポイントの粒度（秒単位）
通常メトリックは1分（60秒）の単位で、高解像度メトリックの場合は1、5 、10、30秒もそれぞれ指定可能。

4.グラフを表示

あとはグラフを表示させるだけ、と思いましたが手順通りやっても表示されませんでした。
おそらく何かがおかしかったのだと思いますが、ちょっと時間が無いので今日はここまで（宿題）

参考URL

https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-data.html

https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-statistics.html

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-04T02:18:59+09:00

AWSの10分間チュートリアルをやってみる 1.AWS コストの管理

こんにちは。トリドリといいます。
新卒で入社した会社でJavaを数年やった後、1年ほど前に転職してからはRailsを中心に使用してアプリケーションの開発をしているしがないエンジニアです。

今回、AWSの勉強をするために公式の10分間チュートリアルをやってみることにしたので、備忘のために記事に残していこうと思います。
AWSに関しては、１年ほど前転職活動をしていた時期にEC2とRDSを少し触っていた以外ほとんど触ったことが無い初心者です。
（ただし、このときにアカウントを作ったので、12ヶ月の無料枠は切れていました）

AWS コストの管理

https://aws.amazon.com/jp/getting-started/tutorials/control-your-costs-free-tier-budgets/?trk=gs_card

チュートリアルのページを開いて、一番左上にあったのでこれを最初のチュートリアルに選択。
このあたりを何も調べないままEC2とRDSを触っていた結果、気がつくと無料枠を超えて料金が発生していた１年前の思い出が蘇ります。

1.AWS 無料利用枠を調べる

無料枠にはサインアップしてから12ヶ月無料のもの・無期限に無料のもの・トライアルで指定の期間やオペレーション数まで無料のものの３タイプあること、無料枠についてのページがあり各タイプごとにどのサービスのどのような条件が無料枠として用意されているのかを調べられることが記載されています。
貼ってある画像はおそらく古いバージョンで、現在のページとはデザインが異なっていました。

前述の通り、無料枠の存在はすでに認識していたので、さらっと流します。

2.AWS にサインアップする（またはサインイン）

次のステップでログインが必要なページを見るため、サインアップまたはサインインをするだけのステップです。
今回はIAMユーザーでログインしました。

3.コストと無料利用枠の使用量を確認する

a.請求ダッシュボードにアクセスする

請求ダッシュボードを開いて見ていきます。
が、ここで問題が発生しました。
image.png
この通り、権限が必要と言われてしまいました。
ログインしているIAMユーザーにBillingの権限は付与されているのになぜ…と思いながらエラーメッセージのリンク先を確認します。
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_billing.html
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/grantaccess.html

どうやら請求ダッシュボードへIAMユーザーがアクセスするためには、Billingの権限とは別にrooｔユーザーがアクティベートする必要があるようです。
手順に従ってアクティベートしたところ、無事開くことができました。

b.請求ダッシュボードを確認する

無事ダッシュボードを開くことができたので、内容を確認します。
しかし、最近使っていなかったのでなんの面白みもありません。
これからチュートリアルを進めていけば、きっと面白みも出てくることでしょう。

c.無料利用枠の上位のサービス使用量を分析する

コンソール左下の「使用状況別の上位無料利用枠サービス」を確認します。
こちらも同じく空っぽ、と思いきやデータがありました。
どうやら１年前に無料枠からはみ出した分は対応したものの、無料枠の範囲内のものは対応し忘れていたようです。

d.無料利用枠のすべての使用量にアクセスする/e.無料利用枠のすべての使用量を分析する

「使用状況別の上位無料利用枠サービス」の「すべて表示」を押すと表示できます。
c.同様、対応し忘れていたらしいデータが少し入っていました。

f.AWS 無料利用枠の使用量制限の E メールアラートを変更する

うっかり使用量制限を超えて請求が発生してしまった、という私のような事態を防ぐためにも、アラートメールの設定をしておくことは大切ですね。
ここも画像と実際の画面では変更が入っており、ナビゲーションバーの「設定」の中の「Billingの設定」になっています。

4.コスト予算を設定する

続いてコストに対する予算とその予算に対する３つの通知を設定します。
以前の自分のように予期せぬ請求にびっくりしないでも良いようにしっかり設定していこうと思います。

a.予算を作成する

createボタンから、コスト予算を作成します。
現在は予算が作成されていないので、他のことはできませんが、

b.予算の詳細を設定する

今回はチュートリアルに従って、名前と金額のみを設定して予算を作成します。
○月までのような期限のある予算・月ごとに金額の異なる予算・サービスやユーザー、リージョンなどを組み合わせた単位での予算などもっと詳細な予算を設定することができるようですが、現状の自分には必要ないので金額のみを設定します。

c.実際のコストが予算の閾値の 50% を超過したときのアラートの設定をする/d.予想されるコストが予算を上回る場合のアラートを設定する/e.実際のコストが予算を超えた場合のアラートを設定する

実際のコストまたは予想コスト、予算の割合または金額の組み合わせでアラートを設定することができます。
チュートリアルでは、金額を元にしたアラートの設定はありませんでした。

f.新しい予算を確認する

作成が完了すると、作成済みの予算のリストが表示されます。
予算サービスの無料枠は１ヶ月あたり62予算日ということなので、１ヶ月丸々の予算であれば２つまで無料です。

g.新しい予算を調べる

予算のリストをクリックすると、詳細を見ることができます。
予算の作成時にもあった過去の実績のグラフだけでなく、過去の実績を表形式で見ることや現在の実際のコストや予想コストと予算の比較もできる様になっています。

まとめ

去年の自分はまずこれを見るべきだったと反省する内容でした。
最初に見て設定してからEC2やRDSを触れば、気がついたら請求されていた事態は防げたのに…
今後は設定を定期的に見直し、予想外の請求を防ぐことができるようにしていきます。

次回は、「推奨する次のステップ」の「仮想マシンの起動」に進む予定です。

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

日付別

タグ一覧