AWS関連用語まとめ

個人的に今勉強中のAWS関連の用語をなるべく簡単にまとめてみました。(語弊がある部分もあるかもしれませんが個人的に理解できる形で落とし込んでみました)。今後も随時追加予定

EC2

仮想サーバ

S3

Amazon Simple Storage Service。オンラインストレージサービス

EBS

Amazon Elastic Block Store。オンライン外付けストレージ

ELB

Elastic Load Barancing。ロードバランサー

EIP

Elastic IP。固定のグローバルIP

RDS

Relational Database Service。クラウド型RDBMS

AMI

Amazon Machine Image。ソフトウェア構成(オペレーティングシステム、アプリケーションサーバー、アプリケーションなど)を記録したテンプレート

IAM

AWS Identity and Access Management。AWSへのアクセスを安全に制御するための仕組み

VPC

Virtual Private Cloud。仮想プライベートクラウド。

CloudFormation

環境設定に関してソースコード化したものを読み込んでAWS上に環境構築してくれるサービス(インフラをコード化してくれるなんてすごいね)

CodePipeline

システムのリリースにおけるプロセスを監視し、自動化・視覚化してくれるサービス。GitHubでMasterブランチへのマージを検知し→ビルド→デプロイ作業を自動で行ってくれる、みたいな事ができる

CodeBuild

CodePipelineで連携している機能の一部。自動でビルドしてくれる

CodeDeploy

CodePipelineで連携している機能の一部。自動でデプロイしてくれる

続きを読む

Lambdaのポイントメモ

概要

Lambdaで開発する時に、「あれどうだっけな」ってなった時のメモです。

Lambda関数の種類

  • 同期呼び出し

    • ストリームベース

      • Kinesis Streams
      • DynamoDB Streams
    • それ以外
      • Cognito
      • Echo
      • Lex
      • API Gateway
  • 非同期呼び出し
    • S3
    • SNS
    • CloudFormation
    • CloudWatchLogs
    • CloudWatchEvents
    • SES
    • CodeCommit
    • Config

イベントソース

ストリームベースのイベントソース

  • 通常のイベントソースはイベントソースがLambda関数を呼び出す。
  • ストリームベースのイベントソースは、Lambdaがストリームに対してポーリングを行ない、変更や新しいイベントの存在を検出したらレコードを取得し、Lambda関数を実行する。

アクセス権限

アイデンティティベースのポリシー

  • IAMユーザー、IAMグループ、IAMロールに対してアタッチするポリシー

リソースベースのポリシー

  • Lambdaに対してアタッチされるポリシー
  • Lambdaにイベントソースをセットアップして、サービスまたはイベントソースに対して、Lambda関数を呼び出すアクセス権限を付与する。
  • ポリシーの付与には、AWS CLIかAWS SDKを用いて指定する。

クロスアカウントアクセス

  • Lambda関数を所有するアカウントとそれを呼び出すアプリケーションやイベントソースのアカウントが別でも呼び出せる。

テスト

  • ユニットテストはローカルで実行、これ以外はクラウド上で実行する。

    • ユニットテストは比較的手元で実行したい事が多いテストだから。
  • Lambda関数をローカルで実行するた為に必要なもの
    • ローカルで呼び出す為のエントリポイント
    • イベント
    • contextオブジェクト

エントリポイント

  • ローカル環境で実行する際の呼び出しをどの様に行うか。
  • 実行関数を作って、if文で制御して普通に実行する。

イベントデータ

contextオブジェクト

  • contextオブジェクトには実行中のLambda関数のランタイム情報が格納されている。
  • ハンドラ内部からcontextオブジェクトの各プロパティならびにいくつかのメソッドにアクセスが可能。
  • 極論、ランタイム情報へのアクセスが不要であれば、ローカル実行時は特にエミュレートしなくとも良い。
  • 言語毎に用意されているプロパティ名やメソッド名は異なる

VPC

  • Lambda関数からVPC内にあるパブリックなIPを持っていないAWSリソースにアクセスする事が可能。

    • VPC内のみの接続にしてあるRDSの接続も可能
    • インターネットからアクセスがサポートされていないElastiCacheの様なサービスでも呼び出し可能

アクセス制御

  • EC2やRDSのLambda制御を行いたい場合は、セキュリティグループで行う事ができる。

レイテンシ

  • VPC内のリソースへのアクセスはレイテンシ増の原因となりやすい為、アクセスは最低限にするべき。

    • ENIの作成に時間がかかる。

ENIのレイテンシ

  • ENI は新規のリクエストや久しぶりのリクエストが発生した場合自動的にLambdaによって作成される。
  • 初期化処理に時間がかかる。(10~30秒)
  • 2回目以降は普通のレイテンシ

RDSとの接続の場合

  1. RDSにLambdaから直接レコードを書き込むのではなく、一旦DynamoDBにレコードを書き込み、その時点でレスポンスしてします。
  2. その後、DynamoDB ストリームとLambdaを利用して、非同期にRDSへとデータを反映する。

環境変数

  • 関数からアクセス可能な環境変数を定義する事が可能。

    • コードの変更なく動的に設定した値を渡せる。
    • 無駄なハードコーディングが不要になる。
  • 環境変数へのアクセスは言語毎に変わる。

環境変数の利用制限

  • 合計サイズが4KB
  • 文字で始める
  • 英数字とアンダースコアのみ
  • AWS Lambdaが予約する特定のキーセットは利用不可

Lambda関数自体が利用する環境変数

  • 予約語のうち、更新可能なものと更新不可のものがある。

環境変数の暗号化

  • キーと値はAWS KMS で自動的に暗号化されて保存される。

    • 独自のサービスキーを利用することも可能。

      • 別途IAMロールに対してポリシーが必要。

エラーハンドリング

  • 処理が異常終了した場合の振る舞いは、イベントソースのタイプと呼び出しタイプによって異なる。

    • 関数の実行がタイムアウト
    • 関数の呼び出しがスロットリング
    • 関数の処理でエラーor例外が発生

ストリームベースのイベントソースの場合

  • Amazon Kinesis StreamsもしくはDynamoDB Streamsがイベントソースの場合
  • レコードの有効期限が切れるまで再試行され続ける。
    • その間、エラーの発生したシャードからの読み取りはブロックされ、そのレコードのバッチの有効期限が切れるか処理が成功するまで、新しいレコードの読み込みは行われない。
    • レコードの処理順序が保証される。

ストリームベース以外のイベントソースの場合

同期呼び出しの場合

  • 呼び出し元にエラーが返される。
  • 呼び出し元はそのエラーを受け取り、必要に応じてリトライの処理を実装する。

非同期呼び出しの場合

  • 2回自動的にリトライされる。
  • 3回処理が失敗した場合、デッドレターキューが構成されていれば、そのイベントはデッドレターキューとして指定されているSQSのキューもしくはSNSのトピックに送信される。
    • これにより、障害発生時のイベントを取りこぼす事がなくなる
  • デッドレターキューが構成されていなければイベントは破棄される。

デッドレターキュー

  • デッドレターキューは、関数を非同期で呼び出す場合において、2回のリトライ、つまり3回の試行にも関わらず処理が正常終了しなかった場合にそのイベントを指定されたSQSもしくはSNSへと送る仕組み。

    • コードのロジックエラー
    • スロットリング
  • Lambdaでデッドレターキューを設定する前に、キューもしくはトピックを作成しておく必要がある。

終わり

今後も仕様が変わる度にしっかりキャッチアップしていきたいですね。

続きを読む

AWS初心者がインフラ設計/構築を理解するために、まず最初におさえるべき専門用語 15選

【 はじめに 】 ※現在絶賛執筆中!

~ 現段階 (2017/09/25) では、AWSサービスのことをほとんど知らない ~

今回、AWS初心者の僕がインフラ設計/構築の担当者になった。何事も経験だ!」と、自分から手を挙げたものの、
覚えることが多すぎやしないか?と思いつつ、これも自分の伸びしろだと、、まだまだ伸びる証拠だと
ポジティブに捉えて(本田風)
、絶賛AWSサービスと格闘する毎日を送っている自称ITエンジニアの奮闘記である。

【 現状の課題とその解決策 】

作業を開始してから2週間程度が経過した時点で、このまま場当たり的に知識を身に着けて行くのは、
かなり効率が悪いということに気が付いた。( 自分で言うのも何だが遅すぎないか? :man_tone5: )

もちろん現場で起こっている課題を解決しながら、
場当たり的に問題解決能力を知識を身に着けていくことも重要だと思う。

しかしながら、この局面 (AWSのサービスを全く知らない。インフラに関しての知識はゼロ。) においては、
クラウドの基礎知識を体系的に一からきちんと知識を身に着けていく戦法が有効
だと考える。

理由は、下記の通り。


  • 各単語の関係性についても合わせて学習することにより、単語の忘却曲線をより緩やかにすることができる。
    現状の課題 (1) : 単発だと結構すぐに忘れてしまう。
  • クラウドの全体像を把握するスピードが早くなるので、効率よく知識を吸収することができる。
    現状の課題 (2) : 基礎知識を短期間で習得できるので、後々応用が効きやすい。
  • いきなりAWSコンソール画面を触って間違えてしまうといったような無駄が無くなる。
    現状の課題 (3) : 基礎がないので、想定していないミスをするケースも。。(痛い目に合うのも大事だけどw)

上記のような理由より、自分の知識を蓄積し、常にアップデートしていくため手段 (備忘録) として、
Qiitaに思考プロセス等を書き残していこうと思う。

(他の人がこれを読むことで勉強になるかどうかは分からないですが、、。)

【 対象読者のみなさん 】

  • 業務でインフラを担当することになったけど、どうしたら良いのかイマイチ分からない人
  • インフラ構成図を見て一通り内容を理解しておきたい人
  • AWSインフラに興味があるけど、触ったことがない人

etc ..

【 お願い 】

もし、本記事の内容に「誤り・誤字」があれば、遠慮なくお気軽にご指摘いただければ幸いです。

それでは、AWSでのインフラ構築担当になってまず最初に覚えたワード15選について、
筆者が参考にしたサイト、各概念の分かりやすい表現をPickUp:point_up:!しながら、
ご説明させていただこうと思います。

読んでいただいた方のお役に立てるような記事にしたいと思っていますので、
どうぞ最後までお付き合いください
:grinning: !!!

【 本編 】AWS初心者がインフラ設計/構築を理解するために、まず最初におさえるべき専門用語 15選

まずは、「AWSって何なの?」ってところから。
  
amazon-web-services-logo-large1-e1334297880876.png

00. AWSの基本概念

AWSは、「Amazon Web Service」の略なんだけど、AWSとは?
と何も見ずに語れるほどの知識はないので、この部分に関しては後日アップデートする予定です。

[ 2017/10/13(Fri)時点での、筆者のAWSへ対する認識 ]

クラウドコンピューティングのリソースを提供していて、その上に様々なサービスを乗っけて、
誰でも簡単に?使った分だけの費用(従量課金)でインフラ環境を構築できるサービスってイメージ。

クラウドコンピューティングのリソースというのは、
世界各地にあるAWSが保有しているデータセンターのことなんだけど、、

まず最初に、

どの地域 [リージョン(Region)] のコンピューティングリソースを使用するのか?

ということを決めないといけない。

1. リージョン (Region)

リージョン(Region) 自体は「範囲、領域」を持つ英単語 :point_up:
Amazon クラウドコンピューティングリソース世界各地の多くの場所でホストされており、
これらの世界各地の拠点、物理的に離れている領域のことリージョン(Region)と言います。

2017/10/12(木)時点で、世界中に16個ものリージョン(Region)が存在します。

(以下、「AWS公式サイト」より引用。)

image.png

※今後、さらに5つのリージョンが追加される予定みたいです。(2017/10/12時点)

・中国
・フランス
・香港
・スウェーデン
・米国 (2番目のAWS GovCloudリージョン)

初めてAWSサービスに触れられる方は、とりあえず何も考えずに、
アジアパシフィック(東京リージョン)を選ばれることをお勧めいたします。

※別途リージョン選択についての細かな部分について紹介する記事を書こうと思います。

[参考サイト]


各リージョン内にはかならず2つ以上のアベイラビリティーゾーン (≒データセンター)と呼ばれる拠点があります。

続いては、そのアベイラビリティーゾーンについてご紹介したいと思います。

2. アベイラビリティーゾーン (AZ : Availability Zone)

アベイラビリティーゾーンを物凄く分かりやすく、簡単に言うと、、。

東京リージョン(物理的に離れた地域)= 東京という都市(場所)に、3つの独立したデータセンター(拠点)が存在し、
この各々のデータセンターのことを「アベイラビリティーゾーン(AZ)」と言います。

AWS.jpg

* 1つのリージョン内に2つ以上のアベイラビリティーゾーン(データセンター)が存在するので、
インフラ設計をする際は、複数のアベイラビリティーゾーン(Multi-AZ)を活用することにより、
構築するインフラ/アプリケーションの耐障害性を向上させることができます。

「リージョンとアベイラビリティゾーンに関する概念について」

各リージョンは完全に独立しています。各アベイラビリティーゾーンも独立していますが、
同じリージョン内のアベイラビリティーゾーン同士は低レイテンシーのリンクで接続されています。

リージョンとアベイラビリティーゾーン」より引用

3. VPC (Virtual Private Cloud)

AWSクラウドの論理的に分離した領域 (セクション) を、誰でも簡単に用意することができます。

下図のようなイメージです。

VPC.jpg

この VPC (Virtual Private Cloud) を活用すると自分で定義した仮想ネットワーク内
AWSリソース (ex. EC2,RDS) を起動させることができます。

VPC (Virtual Private Cloud) のIPアドレスは、以下規則で指定することができます。

  • VPC全体で1つのIPアドレスを持つ
  • サブネットでIPアドレス空間を分割する

[ ※注意 ]
ネットワークアドレスは作成後変更不可なので、あらかじめ20ビット以下など、
ある程度のレンジを持つアドレスを設定しておくのが無難です。

[参考サイト]

4. サブネット(Subnet [Public, Private])

サブネットとは、大きなネットワーク (≒VPC) を
複数の小さなネットワークに分割して管理する際の管理単位となる小さなネットワーク (≒サブネット) のこと。

※下図のようなイメージ。

Subnet.jpg

自分で定義したネットワーク(VPC)を複数のネットワークに分割するために使用します。

具体的には、各インスタンスの役割ごとにグループ化 (サブネットに分割) し、
ルートテーブルをアタッチする際などに使われることが多い (きめ細やかなアクセスコントロールが可能) です。

[ パブリックサブネット ][ プライベートサブネット ] の違いについて


まずは、下図をご覧ください!

Subnet2.jpg

上図の通り、インターネットからVPCインスタンスに接続する ためには、
インターネットゲートウェイ (次項で説明) を用意する必要があります。
そして、VPCネットワーク内にあるルーターを介して、各サブネット内のインスタンスへ通信が行われます。

この時、各サブネットにアタッチされているルートテーブル (経路制御表) の内容に沿って、
インターネットからのアクセスを許可するのか、許可しないのかを判断します。

上記の違いで、パブリックサブネット, プライベートサブネットの区別をしています。

  • インターネット(外部ネットワーク)からのアクセスを許可したサブネットを「パブリックサブネット
  • VPC内部の通信のみ許可しているサブネットを「プライベートサブネット

[参考サイト]

5. インターネットゲートウェイ (Internet Gateway)

インターネットゲートウェイは、VPCのインスタンスとインターネットとの間の通信を可能にする
VPCコンポーネント。

こちらのインターネットゲートウェイの役割大きく2つあります。


1. みなさんが作成したVPCネットワークのルートテーブルに、
インターネットへルーティングが可能な宛先を追加すること。

2. パブリックIPv4アドレスが割り当てられているインスタンスに対して、
ネットワークアドレス変換(NAT)を行うこと。


[参考サイト]

6. デフォルトゲートウェイ (Default Gateway)

所属するLANなどの内部ネットワーク (AWS上のサブネット) から、
外部にあるネットワーク(他のサブネットもしくは、インターネット)に通信を行う場合の
出入り口の役割を果たすよう設定されているルーターやコンピューターのことです。

デフォルトゲートウェイは、
ネットワーク上でプロトコル(規約)が異なる複数のデータを相互に変換し通信を可能
にします。

[参考サイト]

7. ルーター(Router)

IP(Internet Protocol)で通信する端末は、まず最初に通信相手が自分と同じネットワーク(同一サブネット内)に
属する端末かどうかを調べ、自身の属するネットワーク外への通信であれば、ルーター(Router)を経由して
通信を行います。

[参考サイト]

8. ルートテーブル (経路制御表:ルーティングテーブル)

ルーターや端末が保持するパケットの配送先に関する経路情報。

VPCの各サブネットをルートテーブル

ルートテーブルの生成・管理方式には、下記2種類が存在します。


・Static Routing (スタティックルーティング)

経路情報を各ルーター内に手動で設定する手法で、
この経路情報は基本的にルート・テーブルより消えることがありません。

・Dynamic Routing (ダイナミックルーティング)

RIP(Routing Information Protocolo)」「OSPF(Open Shortest Path First)
BGP(Border Gateway Protocol)」などのルーティング・プロトコルを用いて、
ルーターが経路情報を自動的に学習する手法で、この経路情報は動的に更新されます。


[参考サイト]

9. NAT (NAT Gateway)

NATとは、Network Address Translationの略称であり、IPアドレスを変換する技術です。
一般的には、プライベートIPアドレスをグローバルIPアドレスに変換する技術とされています。

ex.
企業LAN内のクライアントPCがインターネットに接続する場合に、プライベートIPアドレスを
グローバルIPアドレスに変換する必要があります。

この時に必要になる仕組みが、NAT(NAT:Network Address Translation)です。

10. 踏み台(Bastion)サーバー

メンテナンスの為の接続経路用途で用意されるサーバーのことを指します。

具体的には、アプリサーバー自体が外部(インターネット)から直接SSH接続を受け付けること自体、セキュリティの観点からもよろしくないので、外部からのSSH接続は、アプリサーバーとは別の専用サーバーが受け付けるべきです。そして、そのサーバーからアプリサーバーにSSH接続するといった二段階接続の構えを取ることでセキュアな環境を実現することができます。この時に用意するサーバーが上記の踏み台(Bastion)サーバーとなります。

また、踏み台サーバーは管理者が使用する時間帯以外は停止状態にしておくことにより、
部外者が勝手に侵入するといった心配もなくなるので、セキュアな構成を実現できる仕組みとなります。

(以下、近日中アップデート予定)

11. セキュリティグループ

異なるセキュリティグループに属するインスタンスと通信を行う際に、
トラフィックの制御を行う仮想ファイアウォールとして機能します。

※セキュリティグループはサブネット単位ではなく、インスタンス単位で設定する必要があります。

また、インスタンスを起動 ( 新規作成 ) する際には、対象のインスタンスと1つ以上のセキュリティグループとの
関連付けが必須となります。

[参考サイト]

12. ElasticIP

13. VPCエンドポイント

[参考サイト]

01. アクセスポリシー

AWSでのアクセスポリシーオプション (アクセス制御 ) は、大きく2つに分類されます。

  • リソースベース(S3のバケットやオブジェクトに対して)のポリシー
  • ユーザーポリシー

どのようなアクセス制御をしたいかによって、
リソース自体に閲覧等の権限を付けるもの (リソースベースのポリシー)
ユーザー単位で操作可能範囲を決めるもの (ユーザーポリシー)など、
柔軟性の高いアクセスポリシー設定が可能です。

本記事では、それぞれ代表的なものを一つずつ紹介したいと思います。

14. IAM (Identity and Access Management) 【 ユーザーポリシー 】

ユーザーに対して、AWSへのアクセスを安全に制御するための仕組み。 AWSコンソール画面から設定が可能で、
IAM (Identity and Access Management) の利用自体が課金対象になることはありません。 (基本無料)

IAMを使用することにより、下記のようなケースでアクセス制御を行うことができます。

  • どのユーザーがAWSリソースを使用できるか?
  • (リソースを使用できる場合)どのような方法で使用することが可能か?

[参考サイト]

15. ACL (Access Control List) 【 リソースベースのポリシー 】

リソースごとに少しずつ設定方法が異なるみたいですが、今回はS3()のバケットやオブジェクト
に対してのアクセス管理について紹介したいと思います。

各リソースには、サブリソースとして、ACLをアタッチする必要があります。
このACLによって、アクセスが許可されるAWSアカウントまたはグループと、アクセスの種類が定義されます。

当該リソースに対するリクエストを受信すると、Amazon S3はアタッチされたACLの内容を調べて、
リクエスト送信者がACLの内容を満たしているか判断します。

[参考サイト]

00. ランク外だけど重要なキーワード

16. シークレットキー

[ 筆者失敗談 ]

[※注意!] するほどでもない話。

もし、AWSのアカウントを取得されている方でこれからEC2インスタンスを生成するという方、
S3に新しいバケットを作られるという方はですね、今一度AWSコンソール画面右上のリージョン設定を
ご確認いただくことをお勧めいたします。

image.png

僕は気が付いたら、米国西部 (オレゴン) のリージョンでEC2インスタンスを立ち上げていて、
他のEC2インスタンス(東京リージョンで作成済み)がコンソール画面で確認できないので凄く焦りましたw

みなさんはこんな凡ミスはしないとは思いますが、一応ここに間違えた人間がいるので、記載しておきます。

最後に

今後記事内容をアップデートしていきながら、自分自身もAWSへの知見を深められたらなと思います。
最後までお読みいただき、ありがとうございました (^^)/

続きを読む

AWSの用語と解説

AWS(Amazon Web Services)General_AWScloud.png

インフラ系のクラウドサービスを提供しているAWSは2006年3月から始まり、現在10周年。
アメリカでは政府機関が使っているほど高いセキュリティ

サービスや機能は800個以上あり、もはや中の人も何がいつリリースされたかわからないらしい

Region(リージョン)

AWSは世界中のデータセンターのサーバーで実行されており、サービスを開始する時はリージョンを選択する
リージョンは以下の通り

リージョン
米国東部(バージニア北部) us-east-1
米国西部(オレゴン) us-west-2
米国西部(北カリフォルニア) us-west-1
欧州(アイルランド) eu-west-1
欧州(フランクフルト) eu-central-1
アジアパシフィック (シンガポール) ap-southeast-1
アジアパシフィック(東京) ap-northeast-1
アジアパシフィック (ソウル) ap-northeast-2
アジアパシフィック(シドニー) ap-southeast-2
南米 (サンパウロ) sa-east-1
中国(北京) cn-north-1

アジアパシフィックを選んでおけば問題ないが、特定のリージョンにしかないマイナーなサービスがあったりするので注意が必要

AZ(アベイラビリティゾーン)

リージョン内のデータセンターのことで、
東京リージョンだと ap-northeast-1a ap-northeast-1b ap-northeast-1c のAZがある

EC2(Elastic Compute Cloud) Compute_AmazonEC2.png

仮想サーバ

ブラウザ上で何回かクリックするだけで、簡単にインスタンスが立ち上がる
利用料金はインスタンスタイプや性能にもよるが、最低スペックで 744円/月 くらい?

RDS(Relational Database Service) Database_AmazonRDS.png

リレーショナルデータベース

Amazon Aurora  Oracle  Microsoft SQL Server  PostgreSQL  MySQL  MariaDB
からデータベースエンジンを選択可能

中でも MySQL5.6互換がある Amazon Auroraは1分あたり600万回のインサート、3000万件のセレクトが可能らしい。
下記のサイトによれば、DB性能向上が期待できそう?
http://dev.classmethod.jp/cloud/aws/wordpressdb-migrate-aurora/

Redshift  Database_AmazonRedshift.png

データウェアハウス

2TBから最大1.6PBまでスケール可能でログなどのビッグデータを保存するのによく使用される
カラムナー(列指向)と呼ばれるデータ格納方式が特徴

Redshift は、PostgreSQL 8.0.2 に基づいている。
なので、PostgreSQL 9系で追加されたクエリが使えなかったりする。

ElastiCache  Database_AmazonElasticCache.png

KVSのキャッシュサービス

Memcached・Redis から選べる
Elastic Cacheではなく ElastiCache(エラスティキャッシュ) という名前なので注意が必要

S3(Simple Storage Service) Storage_AmazonS3_bucket.png

オンラインストレージサービス

bucket(フォルダ)
object(ファイル)
という名称がある

1B ~ 5TBまでのオブジェクトを書き込み・読み込み・削除が可能
バケットに容量制限はない

・SLAは99.99%
・静的webサイトのホスティングが可能

CloudFront NetworkingContentDelivery_AmazonCloudFront.png

コンテンツデリバリネットワーク(CDN)

CDNはAkamaiなどがあるが、それに比べると割高

VPC(Virtual Private Cloud) General_virtualprivatecloud.png

仮想プライベートクラウド

Amazon VPCは、AWS上に利用者が占有可能な仮想プライベートネットワークを構築するためのサービス。
このVPCの内部にIPサブネットを作成し、その中に仮想サーバーの「EC2」やデータベースサーバーの「RDS」といったAWSのリソースを配置する。

・ユーザ側で使いたいIP空間(VPC) を作成
・VPCにユーザがサブネットを切ることができる
・サブネット単位で アクセスリストが設定できる

Route53 NetworkingContentDelivery_AmazonRoute53.png

DNSサーバ

DNSは通常マスターとスレーブ構成にすることが多く、2台で構成する場合が多いが
Route53では、4つのネームサーバーで構成され、全世界にDNSサーバーを設置しているので高可用性である
米国:20   欧州:16  アジア:12  オーストラリア:2   南米:2

・SLA100% (ほんとに?)
・DNSラウンドロビンでの負荷分散が可能
料金はかなり安い。

ホストゾーン
0.50 USD(ホストゾーンごと)/月 - 最初の25のホストゾーン
0.10 USD(ホストゾーンごと)/月 - それ以上のホストゾーン

標準的クエリ
0.400 USD(100 万クエリごと) - 最初の 10 億クエリ/月
0.200 USD(100 万クエリごと) - 10 億クエリ以上/月

1つのホストゾーンで、10億クエリ行かなければ、月1ドルかからない。

IAM(Identity and Access Management) SecurityIdentityCompliance_IAM.png

ユーザーの権限を管理できるサービス

ポリシーと呼ばれる権限をユーザーにアタッチすることで、該当ユーザーの操作できる範囲を限ることができる

ポリシーは自由に設定可能で、管理者が細かく設定可能で
例えば、とある管理者が s3-readonly-userを作成し S3の閲覧だけを許可するポリシーを作成してアタッチ。など

随時追加中…

続きを読む

何となくEC2(Amazone Linux)にMariaDBを入れてSpiderで水平Shardingしてみた

雑記と言うか備忘録と言うか、そんな感じでEC2にMariaDBの10.0系をyum経由で導入し、水平Sharding環境を構築しました

#RDS使えばいいんですけど、高いんですよね。それなりにお試しでならEC2を3台構成にすれば水平Shardingは遊べますし。

※構成例

MariaDB:USER / PASS = root / Spider
SERVER:三台 Spiderサーバ:1台 DATANODE:2台
※ IPは仮として
SpiderNode:192.168.10.10
Datanode1:192.168.10.11
Datanode2:192.168.10.12
としますので読み替えてご活用下さい
DB:example_db
table:books
使うエンジン:Spider&Innodb

下準備

yum -y update && shutdown -r now

1.MariaDBインストール
●MariaDBのレポジトリ追加

echo '# MariaDB 10.0 CentOS repository list - created 2014-04-02 07:21 UTC' >> /etc/yum.repos.d/mariadb.repo
echo '# http://mariadb.org/mariadb/repositories/' >> /etc/yum.repos.d/mariadb.repo
echo '[mariadb]' >> /etc/yum.repos.d/mariadb.repo
echo 'name = MariaDB' >> /etc/yum.repos.d/mariadb.repo
echo 'baseurl = http://yum.mariadb.org/10.0/centos6-amd64' >> /etc/yum.repos.d/mariadb.repo
echo 'gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB' >> /etc/yum.repos.d/mariadb.repo
echo 'gpgcheck=1' >> /etc/yum.repos.d/mariadb.repo
echo 'enable=1' >> /etc/yum.repos.d/mariadb.repo

●MariaDBの起動

yum install -y MariaDB-server MariaDB-client

●MariaDB起動

chkconfig mysql on
/etc/rc.d/init.d/mysql start

2.MariaDBの初期設定
●設定適用(対象:全サーバ)


/usr/bin/mysqladmin -u root password 'Spider'
mysql -u 'root' --password='Spider' -e 'CREATE DATABASE example_db;GRANT ALL PRIVILEGES ON *.* TO "root"@"192.168.10.%" IDENTIFIED BY "Spider";FLUSH PRIVILEGES;'

●設定適用(対象:Spiderサーバのみ)
▼MariaDBへのspiderエンジンのインストール

mysql -u 'root' --password='Spider' -e 'source /usr/share/mysql/install_spider.sql'

確認は mysql -u 'root' --password='Spider' -e 'show engines;' にて

●データノードのspiderサーバへの登録(対象:Spiderサーバのみ)

mysql -u 'root' --password='Spider' -e 'CREATE SERVER db1 FOREIGN DATA WRAPPER mysql OPTIONS (USER "root", PASSWORD "Spider", HOST "192.168.10.11", PORT 3306);'
mysql -u 'root' --password='Spider' -e 'CREATE SERVER db2 FOREIGN DATA WRAPPER mysql OPTIONS (USER "root", PASSWORD "Spider", HOST "192.168.10.12", PORT 3306);'

こちらも確認は mysql -u 'root' --password='Spider' -e 'select * from servers;' mysql にて

●スキーマの登録(対象:SpiderNodeのみ)

    CREATE TABLE books
    (
        id int AUTO_INCREMENT NOT NULL,
        name VARCHAR(255) NOT NULL,
        price int(11) NOT NULL default 0,
        created_at DATETIME NOT NULL,
        updated_at DATETIME,
        lock_version int(11) NOT NULL default 0,
        PRIMARY KEY (id)
    ) ENGINE = SPIDER DEFAULT CHARSET=utf8
    PARTITION BY HASH(id) (
      PARTITION p1 comment 'server "db1", table "books"',
      PARTITION p2 comment 'server "db2", table "books"'
    );

●スキーマの登録(対象:db1,db2)

    CREATE TABLE books
    (
        id int AUTO_INCREMENT NOT NULL,
        name VARCHAR(255) NOT NULL,
        price int(11) NOT NULL default 0,
        created_at DATETIME NOT NULL,
        updated_at DATETIME,
        lock_version int(11) NOT NULL default 0,
        PRIMARY KEY (id)
    ) ENGINE = SPIDER DEFAULT CHARSET=utf8
    ;

●Spiderサーバの「my.cnf」設定変更(対象:Spiderサーバのみ)

echo '[mysqld]' >> /etc/my.cnf
echo 'spider_internal_sql_log_off = ON' >> /etc/my.cnf
echo 'spider_remote_sql_log_off   = 1' >> /etc/my.cnf

●Spiderサーバの「my.cnf」設定変更(対象:Spiderサーバのみ)

/etc/rc.d/init.d/mysql restart

お仕舞。

テスト:以下10行のクエリを発行する
※クエリの発行はSpiderサーバのexample_dbで実施

    INSERT INTO books(name, price, created_at) VALUES ('3日で分かるJava', 2500, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('3日で分かるRuby', 2300, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('独習仮想化',      5000, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('Java入門',        2000, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('入門Ruby',        2800, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('Effective Ruby',  4200, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('すごいRuby',      5800, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('Ruby徹底入門',    3000, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('RubyからJavaへ',  1800, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('クラウド大全',    6000, NOW());

●Spiderノード上で全件Select

  MariaDB [example_db]> select * from books order by id;
  +----+----------------------+-------+---------------------+------------+--------------+
  | id | name                 | price | created_at          | updated_at | lock_version |
  +----+----------------------+-------+---------------------+------------+--------------+
  |  1 | 3日で分かるJava      |  2500 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  2 | 3日で分かるRuby      |  2300 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  3 | 独習仮想化           |  5000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  4 | Java入門             |  2000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  5 | 入門Ruby             |  2800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  6 | Effective Ruby       |  4200 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  7 | すごいRuby           |  5800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  8 | Ruby徹底入門         |  3000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  9 | RubyからJavaへ       |  1800 | 2017-09-13 00:06:51 | NULL       |            0 |
  | 10 | クラウド大全         |  6000 | 2017-09-13 00:06:51 | NULL       |            0 |
  +----+----------------------+-------+---------------------+------------+--------------+
  10 rows in set (0.01 sec

●db1ノード上で全件Select

  MariaDB [example_db]> select * from books order by id;
  +----+----------------------+-------+---------------------+------------+--------------+
  | id | name                 | price | created_at          | updated_at | lock_version |
  +----+----------------------+-------+---------------------+------------+--------------+
  |  2 | 3日で分かるRuby      |  2300 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  4 | Java入門             |  2000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  6 | Effective Ruby       |  4200 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  8 | Ruby徹底入門         |  3000 | 2017-09-13 00:06:51 | NULL       |            0 |
  | 10 | クラウド大全         |  6000 | 2017-09-13 00:06:51 | NULL       |            0 |
  +----+----------------------+-------+---------------------+------------+--------------+
  5 rows in set (0.00 sec)

●db2ノード上で全件Select

  MariaDB [example_db]> select * from books order by id;
  +----+----------------------+-------+---------------------+------------+--------------+
  | id | name                 | price | created_at          | updated_at | lock_version |
  +----+----------------------+-------+---------------------+------------+--------------+
  |  1 | 3日で分かるJava      |  2500 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  3 | 独習仮想化           |  5000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  5 | 入門Ruby             |  2800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  7 | すごいRuby           |  5800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  9 | RubyからJavaへ       |  1800 | 2017-09-13 00:06:51 | NULL       |            0 |
  +----+----------------------+-------+---------------------+------------+--------------+
  5 rows in set (0.00 sec)

出来てますね

続きを読む

EMR上でHive2.1から2.3へ

EMR限定なのかどうかは知らないけど、とりあえず書いておく。
某所に怒られたら消そう。ありがとう某所の中の人。

Emr5.8.0はHiveのバージョンが2.3.0になっており、どうやら2.1系とメタストアの互換性がないらしい。そのため、2.1系でRDSとかにメタストア作ってた場合、流用しようとするとクラスタの起動が出来ない。

以下はEMRでの手順を指す。一部手順はEMR使ってない場合でも流用できる気がする。

まず、hive-siteから

javax.jdo.option.ConnectionUserName
javax.jdo.option.ConnectionPassword
javax.jdo.option.ConnectionURL

この3つの設定ふっとばしてローカルのメタストアを向くようにしてクラスタ起動。

その後、masterインスタンスに繋いで/etc/hive/conf/hive-site.xmlを直接編集する。
※rootユーザ

javax.jdo.option.ConnectionUserName
javax.jdo.option.ConnectionPassword
javax.jdo.option.ConnectionURL

この3つがローカル用の設定になってるはずなので、それを今まで2.1系で使ってたRDSの設定を入れる。

その後、hadoopユーザとなり、

hive --service schemaTool -dbType mysql -info

を実行すると、

...
Hive distribution version
Metastore schema version
...

*** schemaTool failed ***

こんなんが出るはず。で、多分2つのversionが違うはずなので、

hive --service schemaTool -dbType mysql -upgradeSchema

...

schemaTool completed

失敗しなけりゃOK。またinfo叩くと今度は成功するはず。
なんかupgradeSchemaの中身は.sqlファイル実行してるだけくさいから直接手動でSQL流すでもいけるんでは?と思いはしたけどやめておいた。

続きを読む