AppSync APIGateway → 複数のAPIエンドポイントを提供 AppSync → 単一のGraphQLのエンドポイントを提供 GraphQL GraphQLの何がいいの？ 必要なデータだけを取得 RestfulなAPIではレスポンスの情報は決まっているので、必要ない情報も全て取得せざるを得ない。 → GraphQLではサーバ側で必要ない情報をフィルタリングして返却する。 一度のリクエストで多くのリソースを取得 RestfulなAPIでは1つの処理をするのにいくつものURLからAPI経由でデータを取得する必要があるケースが多い。 → GraphQLでは1度のリクエストで必要なデータを取得することでパフォーマンス向上を図ることができる。 型を見れば動きがわかる RestfulAPIでは仕様書を見ないとパスからはレスポンスがわからなかった。 → GraphQLではスキーマ定義≒仕様書なので型をみれば何が返るかがわかる。仕様書のメンテコストの削減。 version管理しない RestfulAPIではパスを変えエンドポイントを増やすことでversionを管理するが、管理が大変。 → GraphQLでは呼び出し元で明示的に取得する値を指定するため対応しやすい。@deprecatedを付すことで削除予定であることを明示できる。 データや言語に依存しない 種々の言語に対応。AppSyncではSDL(Schema Definition Language)で記述する。 やってみる スキーマとリゾルバ ▼ スキーマ定義とそこで定義したノードに対応するリゾルバのコンソール ▼ スキーマ定義 ▼ リゾルバ定義 → マッピングテンプレートの文法 データソース = リゾルバの処理する先。どこのデータソースに対してリクエストを投げるか。 Postmanからコールする 参考) https://learning.postman.com/docs/sending-requests/supported-api-frameworks/graphql/ データソースをLambdaとする場合 DynamoDBをデータソースとする場合にはマッピングテンプレートの中で処理を記述していたが、AppSyncから直接アクセスできないRDSやEC2上に独自構築したDBなどをデータソースとする場合にはLambdaを噛ませ、その中に処理を書く必要がある。 リゾルバ DynamoDBの時と違ってLambdaにリクエストを横流しするだけ。種々のクエリはLambda側で処理を振り分ける必要がある。 データソース リゾルバ スキーマ定義のすべてのノードに対してリゾルバをアタッチできる。 なぜ値(ノード)に対してもリゾルバがアタッチできるのか？ → GraphQLがグラフとしての性質を利用していることを考えるとわかる。 → この記事がとてもわかりやすい。 この仕組みにより、上記の例ではrelatedPostが呼ばれた時だけリゾルバで再起的に処理されて値が返され、逆にrelatedPostが呼ばれない時にはこの処理をしなくていいので無駄な演算なくレスポンスを返すことができる。(RestfulAPIではリクエスト側が必要としていないデータだったとしても内部の不要な演算を省いたりできないのでGraphQLのメリットの一つ。) ただし、ここでもしgetPostで生成されるPostノードが複数あり、それぞれに対してrelatedPostを求めるリゾルバを呼ぶとなるとLambdaのコール回数がバカにならないので困る。 そこで、リクエストマッピングテンプレートにてBatchInvokeを指定することですべてのPostを1度のLambdaで処理することができる。 エラーハンドリング Lambdaでエラーした場合、リクエストにエラーの内容が含まれる。

Gemfile gem 'aws-sdk-cloudwatch' 特定インスタンスの CPU 使用率(最大値)を1日分取得する例 metric = Aws::CloudWatch::Metric.new( 'AWS/EC2', 'CPUUtilization', region: region, # 例: 'ap-northeast-1' credentials: Aws::Credentials.new( access_key_id, secret_access_key ) ) result = metric.get_statistics( start_time: Time.now.beginning_of_day, end_time: Time.now, statistics: ['Maximum'], # SampleCount, Average, Sum, Minimum, Maximum を指定可能です period: 60 * 60 * 24, # 1 day dimensions: [{ name: "InstanceId", value: instance_id }] ) result => #<struct Aws::CloudWatch::Types::GetMetricStatisticsOutput label="CPUUtilization", datapoints=[ #<struct Aws::CloudWatch::Types::Datapoint timestamp=2021-04-28 15:00:00 UTC, sample_count=nil, average=nil, sum=nil, minimum=nil, maximum=24.0, unit="Percent", extended_statistics={} > ] > 参照 Class: Aws::CloudWatch::Metric | 公式ドキュメント Rubyからaws-sdkを使ってCloudWatchのメトリックスを取得する | ぺけみさお

Gemfile gem 'aws-sdk-cloudwatch' 特定インスタンスの CPU 使用率(最大値)を1日分取得する例 metric = Aws::CloudWatch::Metric.new( 'AWS/EC2', 'CPUUtilization', region: region, # 例: 'ap-northeast-1' credentials: Aws::Credentials.new( access_key_id, secret_access_key ) ) result = metric.get_statistics( start_time: Time.now.beginning_of_day, end_time: Time.now, statistics: ['Maximum'], # SampleCount, Average, Sum, Minimum, Maximum を指定可能です period: 60 * 60 * 24, # 1 day dimensions: [{ name: "InstanceId", value: instance_id }] ) result => #<struct Aws::CloudWatch::Types::GetMetricStatisticsOutput label="CPUUtilization", datapoints=[ #<struct Aws::CloudWatch::Types::Datapoint timestamp=2021-04-28 15:00:00 UTC, sample_count=nil, average=nil, sum=nil, minimum=nil, maximum=24.0, unit="Percent", extended_statistics={} > ] > 参照 Class: Aws::CloudWatch::Metric | 公式ドキュメント Rubyからaws-sdkを使ってCloudWatchのメトリックスを取得する | ぺけみさお

プログラミング勉強日記 2021年4月29日 VPCの設定 　AWSアカウントを作成すると自動的に各リージョンに1つずつデフォルトVPCとデフォルトサブネットが構成される。 サイズ/16のIPv4 CIDRブロックのVPCを作成する 各AZにサイズ/20のデフォルトサブネットを作成する インターネットゲートウェイを作成してデフォルトVPCに接続する デフォルトのセキュリティグループを作成して、デフォルトVPCに関連付ける デフォルトのネットワークアクセスコントロールリストを作成して、デフォルトVPCに関連付ける デフォルトVPCを備えたAWSアカウントにはデフォルトDHCPオプションセットを関連付ける パブリックとプライベートのDNSホスト名が付与される VPCウィザード 　VPCウィザードを利用することで、頻繁に利用されるVPC構成を瞬時に構成することができる。VPCウィザードはマネジメントコンソールで以下の4つの方式を選択できる。 1個のパブリックサブネットを持つVPCを持つVPC パブリックとプライベートサブネットを持つVPC パブリックとプライベート・ハードウェアVPCアクセスを持つVPC 　(サイト間VPNをオンプレミス側と接続するときの設定を構成するもの。) プライベートのサブネットのみでハードウェアVPNアクセスを持つVPC 　VPCウィザードを利用しない場合は、VPCを作成、サブネットを作成、、と1つずつ作成する。 　

オートスケーリングについて AWS EC2インスタンスの運用時には単体EC2インスタンスの場合でも、 将来的な拡張性に備えてAutoScalingグループ内での運用が望ましいようです。 すべてのEC2インスタンスは、Auto Scaling グループ内で実行されるべきです。たとえEC2インスタンスが1つだったとしても同じです。Auto Scaling グループは、EC2インスタンスをモニタリングし、仮想マシンの論理グループとして機能するもので、しかも無償なのです。 メリット 可用性の向上 負荷分散 運用コストの最適化 ステートレスサーバ化 オートスケーリングはAMI（Amazon Machine Image）を利用して インスタンスをスケーリングする為、 サーバー内に変更点があった場合、 スケーリング時にAMIの時点のサーバーへと先祖返りしてしまいます。 これを回避する為には、 サーバーのステートレス化（サーバーが状態を持たないようにする）を実現する為の アーキテクチャ設計の工夫が色々と必要になってきます。 不安定になったEC2はいつでも捨てられる（Terminateできる）よう内部にデータは保持しないことが重要となります。データを保持していると不安定になった際にインスタンスがTerminateされて、なくなってしまいます。ここでいうデータには次のものが考えられます。 ・アプリケーションで生成された永続的に保管すべきデータ ・アップロードされた画像ファイルなど ・HTTPなどのセッションデータ ・ApacheやTomcatなどのログファイル ・/var/log/messages などOSのログファイル 静的アセット CloudFront(CDN)、S3を用いてサーバー外へ配置 セッション、キャッシュデータ ElastiCache(Redis)を利用したインメモリの外部化 サーバー内ログファイル CloudTrailを利用したログファイルの監視 マウント先のボリューム ElasticFileSystem(NFS)を利用したボリュームのネットワーク共有 もちろんここであげたものはあくまで一例にすぎず ケースに応じたインフラ設計が必要になってくることかと思います。 参考

オートスケーリングについて AWS EC2インスタンスの運用時には単体EC2インスタンスの場合でも、 将来的な拡張性に備えてAutoScalingグループ内での運用が望ましいようです。 すべてのEC2インスタンスは、Auto Scaling グループ内で実行されるべきです。たとえEC2インスタンスが1つだったとしても同じです。Auto Scaling グループは、EC2インスタンスをモニタリングし、仮想マシンの論理グループとして機能するもので、しかも無償なのです。 メリット 可用性の向上 負荷分散 運用コストの最適化 ステートレスサーバー化 オートスケーリングはAMI（Amazon Machine Image）を利用して インスタンスをスケーリングする為、 サーバー内に変更点があった場合、 スケーリング時にAMIの時点のサーバーへと先祖返りしてしまいます。 これを回避する為には、 サーバーのステートレス化（サーバーが状態を持たないようにする）を実現する為の アーキテクチャ設計の工夫が色々と必要になってきます。 不安定になったEC2はいつでも捨てられる（Terminateできる）よう内部にデータは保持しないことが重要となります。データを保持していると不安定になった際にインスタンスがTerminateされて、なくなってしまいます。ここでいうデータには次のものが考えられます。 ・アプリケーションで生成された永続的に保管すべきデータ ・アップロードされた画像ファイルなど ・HTTPなどのセッションデータ ・ApacheやTomcatなどのログファイル ・/var/log/messages などOSのログファイル 静的アセット CloudFront(CDN)、S3を用いてサーバー外へ配置 セッション、キャッシュデータ ElastiCache(Redis)を利用したインメモリの外部化 サーバー内ログファイル CloudTrailを利用したログファイルの監視 マウント先のボリューム ElasticFileSystem(NFS)を利用したボリュームのネットワーク共有 もちろんここであげたものはあくまで一例にすぎず ケースに応じたインフラ設計が必要になってくることかと思います。 参考

AMAZON T2.nano や T2.micro を初期のリソースのまま使っていると ストレージが 8GB なのですぐいっぱいになってしまいます。拡張を試してみました。 作業内容は 「EC2 EBS ボリュームサイズ拡張のやりかた」 https://qiita.com/mangano-ito/items/629b10ea5d1ab80f2cc6 のままです。 そのうえでこの実験では設定後に請求書の確認なども行っています。 環境 AMAZON EC2 ap-southeast-1 (シンガポール) リージョン t2.micro インスタンス OS Ubuntu 18.04 LTS 作業 まず、マネジメントコンソールで拡張したいインスタンス IDを確認 Elastic Block Store の「ボリューム」でアタッチ済み情報から該当ボリュームを探す 該当ボリュームにチェックを付けて「アクション」-「ボリュームの変更」 8 となっているのを 20 に直して「変更」 マネジメントコンソールの画面を読み込み直すと反映していました。 Linux 上での操作 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 32.3M 1 loop /snap/amazon-ssm-agent/2996 loop1 7:1 0 33.3M 1 loop /snap/amazon-ssm-agent/3552 loop2 7:2 0 99.2M 1 loop /snap/core/10958 loop3 7:3 0 55.5M 1 loop /snap/core18/1997 loop4 7:4 0 279.3M 1 loop /snap/nextcloud/27434 loop5 7:5 0 99.2M 1 loop /snap/core/10908 loop6 7:6 0 55.5M 1 loop /snap/core18/1988 xvda 202:0 0 20G 0 disk └─xvda1 202:1 0 8G 0 part / ということで、xvda に 20G が割当らているのが見えます。 パーティションを拡大します。 $ sudo growpart /dev/xvda 1 CHANGED: partition=1 start=2048 old: size=16775135 end=16777183 new: size=41940959,end=41943007 反映しました。 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 32.3M 1 loop /snap/amazon-ssm-agent/2996 loop1 7:1 0 33.3M 1 loop /snap/amazon-ssm-agent/3552 loop2 7:2 0 99.2M 1 loop /snap/core/10958 loop3 7:3 0 55.5M 1 loop /snap/core18/1997 loop4 7:4 0 279.3M 1 loop /snap/nextcloud/27434 loop5 7:5 0 99.2M 1 loop /snap/core/10908 loop6 7:6 0 55.5M 1 loop /snap/core18/1988 xvda 202:0 0 20G 0 disk └─xvda1 202:1 0 20G 0 part / しかしながら・・・ $ df -h Filesystem Size Used Avail Use% Mounted on udev 476M 0 476M 0% /dev tmpfs 98M 896K 97M 1% /run /dev/xvda1 7.7G 7.5G 193M 98% / tmpfs 490M 8.0K 490M 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 490M 0 490M 0% /sys/fs/cgroup /dev/loop0 33M 33M 0 100% /snap/amazon-ssm-agent/2996 /dev/loop6 56M 56M 0 100% /snap/core18/1988 /dev/loop1 34M 34M 0 100% /snap/amazon-ssm-agent/3552 /dev/loop5 100M 100M 0 100% /snap/core/10908 /dev/loop3 56M 56M 0 100% /snap/core18/1997 /dev/loop2 100M 100M 0 100% /snap/core/10958 /dev/loop4 280M 280M 0 100% /snap/nextcloud/27434 tmpfs 98M 0 98M 0% /run/user/1000 ファイルシステムに浸透していないようなので以下のように作業します $ sudo resize2fs /dev/xvda1 resize2fs 1.44.1 (24-Mar-2018) Filesystem at /dev/xvda1 is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 3 The filesystem on /dev/xvda1 is now 5242619 (4k) blocks long. $ df -h Filesystem Size Used Avail Use% Mounted on udev 476M 0 476M 0% /dev tmpfs 98M 896K 97M 1% /run /dev/xvda1 20G 7.5G 12G 39% / tmpfs 490M 8.0K 490M 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 490M 0 490M 0% /sys/fs/cgroup /dev/loop0 33M 33M 0 100% /snap/amazon-ssm-agent/2996 /dev/loop6 56M 56M 0 100% /snap/core18/1988 /dev/loop1 34M 34M 0 100% /snap/amazon-ssm-agent/3552 /dev/loop5 100M 100M 0 100% /snap/core/10908 /dev/loop3 56M 56M 0 100% /snap/core18/1997 /dev/loop2 100M 100M 0 100% /snap/core/10958 /dev/loop4 280M 280M 0 100% /snap/nextcloud/27434 tmpfs 98M 0 98M 0% /run/user/1000 反映しました 値段 今回は、汎用 SSD (gp3) を使うつもりでした。月額 0.096USD/GB ですから、追加12GBで追加1ドル強ぐらい？ 3時間半ぐらい使って 「マイ請求ダッシュボード」で実際の値段を確認。 ありゃりゃ。想定より高いですね。よく見ると gp2 となっています。gp3 を増やすつもりで gp2 にしてしまってました。 また、t2.micro などのインスタンスは時間課金なので3時間半だと4時間分かな？ と思ってましたがカウントは月単位なのですね。4月29日に実験をしてみたので、こういう作業は月初にするのが有利かも知れません。

DockerコンテナをECSでデプロイしようとしていたときに躓いたポイントを共有します。 認証トークンを取得し、レジストリに対して Docker クライアントを認証することができませんでした。 入力したコマンド $ aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ◯◯◯◯◯◯.dkr.ecr.ap-northeast-1.amazonaws.com 結果 An error occurred (UnrecognizedClientException) when calling the GetAuthorizationToken operation: The security token included in the request is invalid. Error: Cannot perform an interactive login from a non TTY device 解決方法 以下、AWS CLIはダウンロードされているものとします。 アクセスキーIDとシークレットキーを取得 https://aws.amazon.com/jp/より、 自身のアカウントタブから「マイセキュリティ資格情報」→「アクセスキー (アクセスキー ID とシークレットアクセスキー)」へ。 私はアクセスキーがなかったため、「新しいアクセスキーの作成」を実行しました。 ここで、アクセスキーIDとシークレットキーの情報が記載されたcsvファイルをダウンロードすることができます。 環境変数変更 アクセスキーIDとシークレットキーの現在の状態を確認します。 $ aws configure list 環境変数の情報をcsvファイルに記載されたアクセスキーIDとシークレットキーに変更。 # hogeにアクセスキーIDを入力。 $ export AWS_ACCESS_KEY_ID=hoge # hugaにシークレットキーを入力。 $ export AWS_SECRET_ACCESS_KEY=huga 再度、アクセスキーIDとシークレットキーの状態を確認します。 $ aws configure list 適切に変更されていたら、ログインしてみましょう。 $ aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ◯◯◯◯◯◯.dkr.ecr.ap-northeast-1.amazonaws.com Login Succeeded 無事、ログインすることができました。 参考 AWSアクセスキーIDとシークレットアクセスキーを取得する方法 AWS ECRでAWS CLIの認証で弾かれた問題

概要 Splunk EnterpriseのSmart Store機能を使用した場合のインフラのコストについて試算してみました。 この記事は、Splunk Enterpriseのアーキテクチャについてやや専門的な知識を持った方を対象にしています。 導入 私は誰？ とある企業のプライベートSOC（セキュリティオペレーションセンター）でSplunkによるログ分析基盤の構築・運用などをしています。 なお、この記事に記載の内容は個人の見解であり、Splunk社や筆者が所属する組織の統一的見解ではないことを、あらかじめお断りします。 Splunkとは Splunkとは、一言で言うと「統合ログ解析・管理ツール」です。様々なログを収集して解析することができ、特にSIEM（Security Information and Event Management）の分野では長年に渡りリーダーの地位を獲得しています。 参考： ガートナー社による2020年SIEM部門マジック・クアドラント Splunkは、データの収集・蓄積・検索・可視化を1つの製品で完結できるので学習コストが低いことと、スキーマレスでまずデータを取り込んで後から様々な加工を行なえる柔軟性の高さが魅力的だと個人的には考えています。RDBや全文検索エンジンなどで似たようなことはできるかもしれませんが、収集・蓄積・検索・可視化を行なうには多くの場合様々な製品を組み合わせる必要があり、そう簡単にはSplunkを代替できないと思います。 なお、特に断りのない限り、この記事内でSplunkと記載した場合は、2021年4月時点で最新版の Splunk Enterprise 8.1 系を指すものとします。 Splunk社はEULAにてベンチマーク結果を勝手に公開することを禁止しています。この記事内で性能について触れている場合は、公開情報からの推測ですのでご承知おきください。 参考： Splunk Software License Agreement Unless otherwise expressly permitted by Splunk, Customer will not and has no rights to: ... (f) provide to any third party the results of any benchmark tests or other evaluation of any Splunk Materials without Splunk's prior written consent; Smart Storeとは Smart Store (略してS2とも言う) とは、SplunkのIndex(Warm Buckets)をローカルストレージの代わりに、AWS S3などのオブジェクトストレージ（リモートストレージ）に格納することができる機能です。Splunkのバージョン7系から実装された機能で、比較的新しい機能と言えます。 Smart Storeを使う最もわかりやすいメリットとして、ストレージのコストを削減できることが挙げられます。特にAWSなどのIaaSの環境でメリットが顕著です。AWS上にEC2でSplunkを構築する場合、Smart Storeを使わないと、EBSにIndexを格納することになりますが、EBSは容量に比例して料金が増大するので、たとえば数十TBの規模になるとかなり高価になってしまいます。 この記事では、Smart Storeを使うことでどの程度コスト削減効果があるのか試算してみました。 参考： Splunk Enterprise - Managing Indexers and Clusters of Indexers - About SmartStore 前提知識 Smart Storeの動作 前提知識として、少しSplunkのIndexerの内部の話をします。 Indexerでは、IndexをBucketという単位で管理します。Bucketはファイルシステム上のディレクトリです。Bucketが複数集まったものをBucketsと呼びます（日本語だとどっちもバケツになってしまいますが）。Bucketsは、データの新しさによって、Hot Buckets、Warm Buckets、Cold Buckets、Frozen Bucketsという段階に分けられており、Bucketに格納されているデータが古くなると順番に移動されていきます。ColdとFrozenは使わない場合もあります。 Splunkでは、Buckets毎に格納先を分けることができます。たとえばHot Bucketsは頻繁に検索されるのでSSD, 古いデータが格納されるCold BucketsはHDDに格納するようなことができます。 Smart Storeを使うと、Hot Bucketsはローカルストレージに書き込みますが、Warm Bucketsに移動するタイミングでAWS S3などのリモートストレージに書き込まれるようになります。 Indexをサーチする場合、Hot Bucketsにあるデータはローカルストレージから直接読み込まれるので、Smart Storeを使わない場合と動作はさほど変わりません。Warm Bucketsにあるデータを検索する場合は、リモートストレージからローカルストレージに一時的にデータを読み込む動作になります。読み込んだデータはローカルストレージにキャッシュされます。 サーチ時にデータがHot Bucketsもしくはキャッシュにないと、リモートストレージから読み込む必要があるのでオーバーヘッドが生じます。Splunk社の資料によると、概ね30%程度の性能低下があるとのことです。 なお、IndexingについてはHot Bucketsが使われるので、Smart Storeのありなしで動作に変わりはないとのことです。 Smart Storeを使う場合、ローカルストレージの容量は少なくて済みますが、キャッシュとしても使われるのでより高いIO性能（IOPS, スループット）が必要になります。IO性能が高いストレージは高価なので、ある程度大容量（つまり長期間）のIndexを保存する場合でないと、Smart Storeのコストメリットは出づらいということになります。 Smart Storeの動作についてはこちらの資料がわかりやすいと思います。 参考： Splunk .conf19 Smart Store Deep Dive Splunk のサイジング Splunkを載せるインフラのサイジングは、（ワークロードが読みづらいWebアプリケーションなどと比べると）比較的容易な部類だと個人的には思います。 Splunk社がリファレンスハードウェアを公開しているので、そのスペックに従えば大幅にサイジングを外すことはあまりないと思います。 サイジングの際に、特に重要だと考えるパラメータは以下です。 1日あたりのログ取り込み容量： 主にIndexerの台数とストレージ容量に関係します 保存期間： 主にIndexerのストレージ容量に関係します 同時サーチ数： 主にSearch Headの台数（CPUコア数）に関係します Indexerの可用性： Indexer Clusterの要否に関係します Search Headの可用性： Search Head Clusterの要否に関係します SF(Search Factor), RF(Replication Factor): Indexer Clusterを使用する場合のストレージ容量に関係します 参考： Splunk Enterprise - Capacity Planning Manual - Reference hardware ストレージ容量の見積もりは、Splunk社が用意しているツールを使うと便利です。 参考： Splunk Storage Sizing Splunk のアーキテクチャ Splunk社は、Splunkのコンポーネントの妥当な構成をまとめた Splunk Varlidated Architecture (SVA) という文書を公開しています。 このSVAと、サイジングの情報があれば、ほとんどの場合において妥当なSplunkの構成を見積もることができると思います。 この記事では、中～大規模構成に対応できて、可用性も確保できる、Distributed Clustered Deployment + SHC - Single Site (C3) 構成をベースに考えます。 参考： Splunk Validated Architectures コスト試算 Splunk要件 前置きが長くなりましたが、ようやくコスト試算に入ります。 Splunkの要件は以下のようなものを考えてみます。 1日あたりのログ取り込み容量： 200GB 保存期間： 3ヶ月 or 1年 同時サーチ数： 20～30程度 Indexerの可用性： 必要 Search Headの可用性： 必要 SF,RF： 2 （Smart Storeを使う場合は値を揃える必要があります） システム構成はSVAを参考に以下のようにします。 見積条件 インフラはAWS上に構築することを前提とします。EC2のインスタンスタイプはSplunk社のホワイトペーパーに準ずることとします。Splunkのリファレンスハードウェアの条件を満たした構成なので、これに従えば大幅にサイジングを外すことはあまりないと思います。 Splunk社によると、Smart Storeを使う場合は、IO性能に優れたi3インスタンスを使用するのがよいようです。c5インスタンスなどでも動くには動きますが、EBSのIO性能が問題になるようです。具体的には、高性能のio2でも最大のスループットは1000MBytes/secですが、S3のスループットは10Gbps（=1250MBytes/sec）に達するのでEBS側がボトルネックになり、キャッシュとしての性能を発揮できないようです。 EBSはSSDとはいっても裏側はiSCSIでつながってるNASみたいなもんで、本物のNVMe接続のSSDと比べると桁違いに性能が低いので当然といえば当然です。 参考： Amazon Web ServicesへのSplunk Enterpriseの導入 参考： Splunk Communityの投稿 i3インスタンスはローカルストレージとしてNVMeのSSDを搭載しているので、キャッシュとして使うのに向いています。注意点として、ローカルのNVMeはエフェメラルストレージ（電源OFF/ONすると消える）なので、実運用するには起動時にLVMを自動設定するなどの工夫が必要になります。 Search Headのインスタンスについては、ホワイトペーパーではc5.9xlargeになっていますが、私の趣味で、AMDのCPUを搭載した似たようなスペックのc5a系のインスタンスで試算してみます。 Splunkはずっと起動しているソフトウェアなので、On Demandインスタンスだとコストパフォーマンスが悪くなります。ここでは、EC2 Instance Saving Plans の1年前払い無しプランで計算してみます。AWSのリージョンは、ap-northeast-1（東京）にします。 コストの計算は AWS Pricing Calculater を使用します。 参考： AWS Pricing Calculator 構成1： 保存期間3ヶ月、Smart Store なし 保存期間3ヶ月、Smart Store なしという、オンプレのSplunkでもよく使われそうなパターンを見積もってみます。 必要なストレージ容量をSplunk社のサイジングツールで見積もってみます。典型的なログファイルを取り込む場合は、1日あたりの容量と保存期間を入力するだけで、それほど大きくサイジングを外すことはないと思います。 参考： ストレージ容量サイジング（ローカルストレージ） Indexer 1台あたりの必要容量は5.9TBなので、20%ほどファイルシステムの余裕を見て、EBSのサイズは7TBにしておきます。 なお、Indexer故障時の縮退については考慮しないこととします。 見積もり結果は以下のようになりました。月額90万円といったところです。なかなかいい値段ですが、ぶっちゃけこの規模だとSplunkのライセンスの方が高いです。 構成2： 保存期間3ヶ月、Smart Store あり 保存期間3ヶ月で、Smart Store ありのパターンを見積もってみます。 Smart Storeを使う場合は、ローカルストレージとして1ヶ月程度の容量を確保するのがよいようです。試算だと2TBですが、i3.8xlargeは1900GBのNVMeストレージが4個付いてるので、それでRAID0を組めば十分な容量と言えそうです。 参考： ストレージ容量サイジング（ローカルストレージ） Smart Storeの必要容量は、SF/RFを考慮しない値と同じになるはずなので、ざっくり10TBとしておきます。 参考： ストレージ容量サイジング（リモートストレージ） 構成1と比べると、EBSのコストは減りますが、i3インスタンスの単価が高いので、構成1より若干高くなってしまいました。この見積条件では、保存期間3ヶ月程度だとコストメリットが出ないようです。 構成3： 保存期間1年、Smart Store なし 保存期間1年、Smart Store なしのパターンで見積もってみます。必要なストレージ容量は70TB程度になってきます。今どきのオンプレのストレージだと70TBはもはや小容量ですが、EBSだとなかなかの大容量だと思います。 余談ですが、逸般的な誤家庭の住人だと自宅に100TB超のストレージを持ってる人もいるとかいないとか。我が家はまだ一般的だと思いますが、生のストレージの容量を合計すると30TBくらいはあります。AWS上に大容量のデータを置くなら、EBSのような高価なストレージを使うとコストがつらいですね。 Indexer 1台あたりの必要容量は23.4TBなので、構成1と同じ考え方で、EBSのサイズは28TBにしておきます。なお、EBS1個あたりの容量は16TBまでなので、この場合は1台のEC2に複数のEBSをアタッチしてRAID0を組むなどの対応が必要になります。 参考： ストレージ容量サイジング（ローカルストレージ） 構成1と比べるとEBSの容量だけが違いますが、これだけの容量のEBSを使うと、EBSのコストがEC2のコストを超えて支配的になってきますね。 構成4： 保存期間1年、Smart Store あり 保存期間1年、Smart Store ありのパターンで見積もってみます。Indexの大部分はS3に保存されるようになるので大きなコスト効果を見込めそうです。 Smart Storeの必要容量は、構成2と同じ考え方で、ざっくり40TBとしておきます。 参考：ストレージ容量サイジング（リモートストレージ） 構成3と比べると月額で60万円程度のコスト削減効果を見込めそうです。保存期間が長くなると、Smart Store のコストメリットが効いてきますね。 比較 グラフで比較すると以下のようになります。保存期間の長さと、Smart Storeのありなしで、EC2とストレージ（EBS/S3）のコスト構造が変わることがよくわかると思います。 まとめ Splunk Smart Store を使う場合のインフラのコストを試算してみました。 Indexの保存期間が長い場合は、Smart Storeを使うことでコスト削減できそうであることがわかりました。しかし、保存期間が短い（概ね3ヶ月程度）の場合は、コストメリットが出づらいことがわかりました。Smart Storeのメリットはコスト以外にもあるので、サーチ性能の低下や、高価なインスタンスタイプを使う必要があるなどのデメリットとのトレードオフで考えるのがよいと思います。 AWSなどのIaaS上でSplunkを利用するときは使ってみる価値があると思いますので、参考にしてもらえればと思います。

概要 EC2に任意のPHPをインストールする 初期状態のEC2にはPHPはインストールされていない [ec2-user@ec2-php ~]$ php -v -bash: php: command not found PHP 5.4 amzn2-coreに入ってるのでyumでインストールするだけ [ec2-user@ec2-php ~]$ yum list | grep php php.x86_64 5.4.16-46.amzn2.0.2 amzn2-core [ec2-user@ec2-php ~]$ sudo yum install -y php php-mbstring [ec2-user@ec2-php ~]$ php -v PHP 5.4.16 (cli) (built: Oct 31 2019 18:34:05) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies PHP 7.2 7.3 7.4 8.0 amazon-linux-extrasに入ってるので適宜有効にしてインストール [ec2-user@ec2-php ~]$ amazon-linux-extras | grep php 15 php7.2 available \ 17 lamp-mariadb10.2-php7.2 available \ 31 php7.3 available \ 42 php7.4 available [ =stable ] 51 php8.0 available [ =stable ] [ec2-user@ec2-php ~]$ sudo amazon-linux-extras enable php7.2 15 php7.2=latest enabled \ [ =7.2.0 =7.2.4 =7.2.5 =7.2.8 =7.2.11 =7.2.13 =7.2.14 =7.2.16 =7.2.17 =7.2.19 =7.2.21 =7.2.22 =7.2.23 =7.2.24 =7.2.26 =stable ] [ec2-user@ec2-php ~]$ sudo yum clean metadata && sudo yum install -y php php-mbstring [ec2-user@ec2-php ~]$ php -v PHP 7.2.34 (cli) (built: Oct 21 2020 18:03:20) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies PHP 7.2.* 7.3.* 7.4.* 8.0.* amazon-linux-extrasでPHPを有効にする際にバージョンを指定することも可能 [ec2-user@ec2-php ~]$ sudo amazon-linux-extras enable php7.2=7.2.16 15 php7.2=7.2.16 enabled \ [ =7.2.0 =7.2.4 =7.2.5 =7.2.8 =7.2.11 =7.2.13 =7.2.14 =7.2.16 =7.2.17 =7.2.19 =7.2.21 =7.2.22 =7.2.23 =7.2.24 =7.2.26 =stable ] [ec2-user@ec2-php ~]$ sudo yum clean metadata && sudo yum install -y php php-mbstring [ec2-user@ec2-php ~]$ php -v PHP 7.2.16 (cli) (built: Apr 3 2019 18:39:35) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies amazon-linux-extrasで有効なPHPを切り替える amazon-linux-extrasで異なるバージョンのPHPを有効にしようとすると怒られる [ec2-user@ec2-php ~]$ sudo amazon-linux-extras enable php7.2 [ec2-user@ec2-php ~]$ sudo amazon-linux-extras enable php8.0 Refusing because php8.0 could cause an invalid combination. 有効にしているPHPを無効にしてから再度有効にする必要がある [ec2-user@ec2-php ~]$ sudo amazon-linux-extras disable php7.2 [ec2-user@ec2-php ~]$ sudo amazon-linux-extras enable php8.0 51 php8.0=latest enabled [ =stable ] それ以外のバージョンのPHPをインストールする aws関連からは提供されていなさそうなのでremiからインストール [ec2-user@ec2-php ~]$ sudo amazon-linux-extras install -y epel [ec2-user@ec2-php ~]$ sudo yum install -y https://rpms.remirepo.net/enterprise/remi-release-7.rpm [ec2-user@ec2-php ~]$ sudo yum install -y php56 php56-php-mbstring [ec2-user@ec2-php ~]$ sudo . /opt/remi/php56/enable [ec2-user@ec2-php ~]$ php -v PHP 5.6.40 (cli) (built: Apr 28 2021 14:35:32) Copyright (c) 1997-2016 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies PHPを削除する 新しくPHPをインストールする場合は削除してからインストールする sudo yum remove -y php-* 注意事項 後は必要に応じてPHP拡張をインストール 参考

はじめに Golang のエラーハンドリングは、基本的に error 型に詰め込まれた情報を扱う。 nil 値以外かどうかを判別するのは大したことがないが、error 型が interface があるがゆえに自由度が高く、真面目にハンドリングしようとするとちょっと厄介である。 参考: 【Qiita】Golangのエラーハンドリングの基本 今回は、 AWS SDK for Go でどのようにエラーハンドリングをしたら良いか、DynamoDB を例に取って確認する。 なお、基本的にAPIリファレンスにハンドリング付きの例があるので、これを見れば済む話ではある。 PutItem() のような単純なエラー AWS SDK for Go のエラー情報は、基本的に型アサーション(Type assertions)で取得する。 PutItem() の場合は、以下のような感じだ。 DynamoDBのテーブルには、あらかじめ id:00001 のユーザを入れておき、ConditionExpression でエラーになるようにしておく。 if _, err := svc.PutItem(&dynamodb.PutItemInput{ TableName: aws.String(ddbTableName), Item: map[string]*dynamodb.AttributeValue{ "id": { S: aws.String("00001"), }, "name": { S: aws.String("Taro"), }, "age": { S: aws.String("36"), }, }, ConditionExpression: aws.String("attribute_not_exists(id)"), }); err != nil { log.Println(reflect.TypeOf(err)) if awserr, ok := err.(awserr.Error); ok { log.Println("awserr.Code(): " + awserr.Code()) log.Println("awserr.Message(): " + awserr.Message()) } } これを実行すると、以下のような出力となる。 2021/04/29 14:31:07 *dynamodb.ConditionalCheckFailedException 2021/04/29 14:31:07 awserr.Code(): ConditionalCheckFailedException 2021/04/29 14:31:07 awserr.Message(): The conditional request failed interface で dynamodb.ConditionalCheckFailedException が渡されてくるようだ。 awserr.Code() で分岐を作れば、エラーハンドリングが可能になる。 PutItem() は構造が単純だが、では TransactWriteItems() のように複数のアイテムの情報を扱うような複雑な構造の場合はどうだろう？ TransactWriteItems() のような複雑なエラー まずは PutItem() のように書いてみよう。 今度は、1件目の id:00002 は正常に処理が行えて、2件目の id: 00001 で ConditionExpression となってエラーになるようにしておく。 if _, err := svc.TransactWriteItems(&dynamodb.TransactWriteItemsInput{ TransactItems: []*dynamodb.TransactWriteItem{ { Put: &dynamodb.Put{ TableName: aws.String(ddbTableName), Item: map[string]*dynamodb.AttributeValue{ "id": { S: aws.String("00002"), }, "name": { S: aws.String("Jiro"), }, "age": { S: aws.String("25"), }, }, }, }, { Put: &dynamodb.Put{ TableName: aws.String(ddbTableName), Item: map[string]*dynamodb.AttributeValue{ "id": { S: aws.String("00001"), }, "name": { S: aws.String("Taro"), }, "age": { S: aws.String("36"), }, }, ConditionExpression: aws.String("attribute_not_exists(id)"), }, }, }, }); err != nil { log.Println(reflect.TypeOf(err)) if awserr, ok := err.(awserr.Error); ok { log.Println("awserr.Code(): " + awserr.Code()) log.Println("awserr.Message(): " + awserr.Message()) } } これを実行すると、 2021/04/29 14:37:10 *dynamodb.TransactionCanceledException 2021/04/29 14:37:10 awserr.Code(): TransactionCanceledException 2021/04/29 14:37:10 awserr.Message(): Transaction cancelled, please refer cancellation reasons for specific reasons [None, ConditionalCheckFailed] という出力になる。 これでは、TransactionCanceledException の原因を拾って条件分岐させることができない。 TransactionCanceledException は、APIリファレンスによると、CancellationReasons というエラー理由の配列を持っているようだ。 なので、リファレンスで CancellationReasons の構造体を追いかけ、さらに以下のようにこの配列の中身を見てみる。 TransactionCanceledException であることを確実に判別したうえでハンドリングする必要があるため、err.(type) で switch を作り、何の型が帰ってきているかを特定しよう。 }); err != nil { log.Println(reflect.TypeOf(err)) if awserr, ok := err.(awserr.Error); ok { log.Println("awserr.Code(): " + awserr.Code()) log.Println("awserr.Message(): " + awserr.Message()) } switch t := err.(type) { case *dynamodb.TransactionCanceledException: log.Println(*t.CancellationReasons[0].Code) log.Println(*t.CancellationReasons[1].Code) default: log.Printf("failed to write items: %v", err) } } これで、 2021/04/29 14:46:18 awserr.Code(): TransactionCanceledException 2021/04/29 14:46:18 awserr.Message(): Transaction cancelled, please refer cancellation reasons for specific reasons [None, ConditionalCheckFailed] 2021/04/29 14:46:18 t.CancellationReasons[0].Code: None 2021/04/29 14:46:18 t.CancellationReasons[1].Code: ConditionalCheckFailed という出力が得られ、TransactionCanceledException の発生理由の条件分岐が作れるようになった！ 基本はこのような感じなので、他の API についても、この要領でハンドリングをすることが可能だろう。

要約 AWSの試験を受けると より多くの技術が自分ごとになるよ おまけで資格がついてくるよ AWSの認定試験とはなんですか パブリッククラウド上でのアプリケーションの開発・運用基盤を提供する クラウドサービスの最大手 AWS が実施する資格試験のこと AWSの提供するサービスについての理解度を試験を通して確認・証明するためのしくみですが 後述のとおり「AWSの知識証明」にとどまらない受験メリットもあるよ AWS認定試験はこんな人にオススメ 社会人になってからプログラミングを始めた 要件をみたすプログラムを自力で書ける程度の力がついてきた 開発者としてのキャリアパスにいまひとつ自信がない、悩んでいる このあたりに当てはまるなら、 AWSの認定試験を受けてみることは、ポジティブな結果を期待できるかも おもなオススメ理由 「クラウド」の利点をより深く理解できる 問題をアーキテクチャで解決する思考訓練になる ネットワーク技術知識のキャッチアップになる 1. 「クラウド」の利点をより深く理解できる クラウドサービスの代表的な利点のひとつは、物理的なハードウェアの導入・保守コスト(運搬、配線工事、災害対策など)を放棄しながら ハードウェアの機能のみを、物理的制約を超えてより柔軟に享受できることにあります。 (ネットワークつなぐのにLAN線要らず、Webの管理画面上の接続操作で作業完結、とか) 資格試験は、このクラウドの利点を軸に『非クラウドの運用上の問題を、クラウドで解決するためにはどうする？』という観点がしばしば含まれます。 クラウドじゃないとこんだけ困る！ クラウドだったらこうなる！ …という組で理解していくことになるので、クラウドの利点を、具体的な事例をもって理解に落としこめます。 各社サービスで機能差はあれど、主要なメリットは等しくカバーされるでしょうから、 クラウドサービス一般に通用する納得感が(運用経験なしに)得られるのは、資格受験の強みであるように思えます。 ２．問題をアーキテクチャで解決する思考訓練になる 認定試験においては、アプリケーションの動作基盤であるインフラの信頼性(極力ダウンしない、復旧が早い など)を確保する方法についての問題が多く出題されます1。 インフラにおける信頼性は、おもに(機能自体の実装というよりは)機能どうしをどういう構成で配置するか、というアーキテクチャによって実現されます。 アーキテクチャによって信頼性を担保するという発想は、プログラムの記述においても非常に重要です。 プログラムが拡張性やトラブル耐性(不具合が出たときの影響範囲の限定能力とか)といった要素を獲得するためには『ソースコードをどうまとめ、まとまりをどう組み立てるか』というアーキテクチャ思考の寄与するところが大きいためです。 プログラムの話はプログラム向けの書籍を読む、が手っ取り早いかもしれませんが、 AWSの試験は前述のとおりケーススタディが多いという点で理屈をつかみやすく、考え方をとらえる良い題材になりえるように思えます。 ３．ネットワーク技術知識のキャッチアップになる １．に近い観点で、主にWeb系のかた向け。 たとえばかけだしWebエンジニアなら、多くの場合、ネットワークプロトコルを理解しなくても業務を遂行できる状況にあるでしょう。 一方で、これらの知識はWebアプリケーションにとっては大前提ですから、たとえば技術選定などのフェーズにおいては、これらの知識は選定基準の裏付けになりえます。 仕様から固める、技術を選ぶ、といったフェーズに職務範囲を広げたい方には避けがたい領域…と考えると 嫌でもネットワーク周辺の知識に触れることになるAWSの認定試験は、勉強のいい口実になってくれるでしょう。 おわりに たまたま機会があったのでAWS SAAの試験を受けたのですが、 調べることを後回しにしてきたこと/まったく知らなかったこと、どちらも学ぶいい機会になったと感じたので、過去の自分に書くような気持ちで書きました。 AWSの資格取得はあくまで選択肢のひとつですが、 ・実施のハードルが低め( 一人でできる、出版物多い、難度選べる ) ・履歴書に書けるおまけつき ...という点で、実現性と実用性にすぐれるように思えます。 将来のために何をすればいいかわからない、とっかかりがほしいと望んでいるエンジニア(とくにWeb系)の方は、やらないよりは大方ハッピーな結果になると思います。ご検討ください ※AWS からお金をもらって書いたわけではありません お金ください 　GCPやAzureにも同じような資格制度があります。興味があるものを受けるといいと思います 私が受けたSolution Architect Asociateの試験はこれが主要なトピックのひとつでした。ほかの資格タイプだと、あまり問われないかもしれません。Solution Architect(SA)がいちばん領域的には広く扱うようなので、資格種に悩むなら、サービス全体を鳥瞰できるSA受験がいいのかなと個人的に思っています。 ↩

0.はじめに AWS ground stationは、衛星通信のコントロール、衛星データの処理、衛星運営のスケーリングを可能にする完全マネージド型サービスです。 ？？？？？？？？ 何ができるのかよく分からない。 衛星は、天気予報、地表画像撮影、通信、放送など、幅広いユースケースで使用されています。 ？？？？？ Ground stations は、グローバルな衛星ネットワークの中心を形成しています。 AWS Ground Station では、AWS のサービス、ならびに、低レイテンシーのグローバルファイバーネットワークを含む AWS のグローバルインフラストラクチャへの、直接的なアクセスが提供されます。 つまり何ができるんだろう。 1.コスト まずは、利用コストについてのお話です。 お高いんでしょう…？？？ と思いきや、なんとなんと 1分あたり3 USD～22 USD 1時間辺り日本円で2万円から15万円くらいでしょうか。 …めちゃくちゃ高い。 2.使用までの流れ まず大前提として、アメリカのアマチュア無線的なライセンスが必要らしいです。 上記のORAD IDとFCCライセンスを登録後、AWSコンソールから、衛星のスケジュールを予約します。 Federal Communications CommissionでFCC、連邦通信委員会のライセンスらしいです。 NORAD IDは北アメリカ航空宇宙防衛司令部の衛星の管理番号だとか。。。 そしてスケジュールの時間が来たら、衛星と通信し、データを取得して、AWSの様々なサービスに連携して活用する事が可能です。 全然分からない... 3.何に使えるのか 結構幅広い分野での使用が期待されているようです。 例えば、独自で衛星写真を入手したいとき。 災害情報などを即時に察知する。 グローバルなデータ通信を行いたい。 AWSの各データ分析サービスとの連携が可能なようなので、 入手したデータは、Amazon Kinesisなどでリアルタイムストリーミングで処理して、S3に保存したり、 AWS SageMakerでそのまま分析を行ったり... う～ん、、、何に使えばいいんだろう。 実際に使ってみようと思ったら、先ほどのライセンスが登録されないとスケジュールすら建てられないですね。 4.まとめ 雑なまとめですが、日本国内企業が使うのは結構ハードルが高いのではないでしょうか。 FCCライセンス自体は、国内からでも取得可能なようなのですが、 「ground station 使ってみた」で、日本国内の事例、個人の利用が全然見受けられないので、 これから共同利用などでもっと敷居が下がって、GoogleEarthのような感覚で、 衛星画像をリアルタイムで受信する事が出来るようになる日が来るのではないでしょうか。

こんにちは、まゆみです。 AWSについての記事をシリーズで書いています。 今回は第4回目になります。 前回、前々回とIAMの解説をしてきました。 そこで、AWSのサービスの一部を解説したわけですが、ではAWSにアクセスする方法はどのようなものがあるのでしょうか？ AWSのサービスにアクセスする方法は3つあります。 ①パスワードとMFAを利用してコンソールにログインする ②AWS Command Line Interface(CLIと略される)を利用する ③AWS Software Developer KIT(SDK)を利用する 今回の記事では、②のCLIを使ったログイン方法を書いていこうと思います では早速はじめていきますね。 Command Line Interface のインストール (この記事では、Windowsを使って解説しています。Macユーザーの方も基本的に同じ手順でインストールできます。) こちらからCLIインストールページにアクセスしてください。 上のページにいきましたら、インストーラーをダウンロードしましょう インストーラーをダウンロードしていきます。 『Next』をそのままクリックしていけば大丈夫です。 最後まできましたら、『Finish』をクリックしてください。 無事インストールできました。 ただ、ちゃんと本当にインストールされているのか確かめたいですよね。 そのような方は、コマンドラインに 『aws --version』 と打ち込みましょう aws-cli/version名　Python.... と表示されれば大丈夫です。 アクセスキーとシークレットアクセスキーを作る アクセスキーはユーザーネームのようなもので シークレットアクセスキーはパスワードのようなもの です。 CLIを使ってAWSにアクセスするときに重要となってきます。 また、アクセスキーやシークレットアクセスキーは流出しないようにしましょう。 アクセスキー・シークレットアクセスキーを作ること自体は簡単です。 IAMのダッシュボード > ユーザーから今回アクセスキー・シークレットアクセスキーを発行するユーザーを選びます。 バーに表示されているユーザー名と同じである事を確認してくださいね。 『認証情報』から『アクセスキーの作成』をクリックします すると、アクセスキーが作成されます。 とても大事なものになりますから、.csvファイルのダウンロードと書いてあるところをクリックして、保存しておきましょう コマンドラインでAWSにアクセスする ではさっそくコマンドラインにうちこんでいきましょう まず、『aws configure』と打ち込みます すると、Access Key, Secret Access Key などを聞かれますので、先ほど作ったそれぞれのKeyを貼り付けましょう。 Default region name はあなたの住んでいるところの一番近くを指定します。 regionは、コンソール画面の一番上のバーにある、『グローバル』をクリックして調べてくださいね。 そのあと、 aws iam list-users と打ち込むと、IAMユーザーが全て表示されます。 CLIの代替手段 コマンドラインはちょっと面倒くさい という人には朗報(?)です。 AWS　Clowdshellが代替手段として使えます。 ただ、限られたリージョンでのみ使えるので注意が必要です。 (Clowdshellが使えるリージョンについてはこちらを参考にどうぞ) トップのバーにある赤で囲ったところをクリックすると、Clowdshellが使えます。 まとめ 今回は、CLIについてざっくり解説させていただきました。 また、次回からもAWSについて深堀していきますので、是非記事を読んでみてくださいね。

AWSのCloud9でLaravelを使ってみる PHPのワークフレームであるLaravelを使ってみたいと思い、色々と学んだことを健忘録がてら、まとめようと思います。 特にAmazon Linux2に関しては、調べてもナレッジが少なかったので、他の方の参考になれば幸いです。 AWS上でCloud9を起動し、環境設定を行う AWSにサインイン AWSからコンソールにサインインする。 案内に従って、マネジメントコンソールが表示されるまで進む Cloud9を検索 検索窓でCloud9を検索し選択 environmentを構築する environment=プロジェクトの構築環境を作る。 ますは、「create environment」を選択し、 名前と詳細を記入し、 環境設定を行う。 「Instance type」は無料枠の場合、「t2.micro」を選択する。 また、30分ごとに接続が切れるように設定しないと、気付いたら高額の請求がされる可能性があるので注意。 Laravelの環境設定 environmentの構築が終わると、下のような画面が表示されます。 一番したのwindowはtarminal windowであり、以下もコードをこのwindowに書き込んでいきます。 ＊コマンド入力の最中に質問されることがありますが、全て'y'と答えれば問題ないです。 PHPセットアップ まずはPHP７.２のセットアップ ターミナル $ sudo amazon-linux-extras install php7.2=stable ターミナル $ sudo yum install php-mbstring php-pecl-memcached php-gd php-apcu php-xml MaryaDBの設定 MySQLの上位互換であるMaryaDBを構築 MaryaDBの設築 ターミナル $ sudo amazon-linux-extras install -y lamp-mariadb10.2-php7.2 MariaDBのインストール ターミナル $ sudo yum install -y mariadb-server MariaDBの起動と初期設定 ターミナル $ sudo systemctl start mariadb ターミナル $ sudo mysql_secure_installation 上記のコマンド入力後に初期設定についていくつか質問されるので、以下のように答えます。 新しいパスワードを入力する時、入力の文字は表示されないので注意してください。 <初回設定の入力項目> Set root password? [Y/n] y New password: root Re-enter new password: root Remove anonymous users? [Y/n] y Disallow root login remotely? [Y/n] y Remove test database and access to it? [Y/n] y Reload privilege tables now? [Y/n] y MaridaDBの自動起動を有効化 MaridaDBが自動で起動するように設定。 ターミナル $ sudo systemctl enable mariadb ターミナル $ sudo systemctl is-enabled mariadb Composerインストール PHPのライブラリを管理してくれるComposerをインストールする。 ターミナル $ curl -sS https://getcomposer.org/installer | php ターミナル $ sudo mv composer.phar /usr/bin/composer ターミナル $ composer Laravelインストール composerを利用してcmsという作業ディレクトリを作成しLaravelをインストールします。 ターミナル $ composer create-project laravel/laravel cms 6.* --prefer-dist 今後の作業はこのcmsディレクトリで行います。 サーバーの起動とLaravelの起動 BuiltInサーバーを起動：動作確認 サーバーを起動するために、先ほど作成した作業ディレクトリであるcmsに移動 $ cd cms 下記コマンドを入力しサーバーを起動します。 $ php artisan serve --port=8080 Cloud9の画面上部の緑の起動ボタンの左側PreviewボタンからPreview Running Applicationをクリック 右下に画面が起動してLaravelの文字が確認できたら、Laravelのインストール成功 新しくpop upしたwindowの右上にある「pop up into new window」を選択し、新規タブでLaravelのデモ画面を表示 今後はこの画面で更新した内容を確認する サーバーを起動しているtarminalはそのままに、新しいtarminalを立ち上げておく。 上記までの流れでLaravelの環境設定は完了です。 データベースの作成 新しく立ち上げたターミナルで作業ディレクトリであるcmsに移動 ターミナル $ cd cms 下記コマンドを入力していき、c9というデータベースを作成 ターミナル $ mysql -u root -p パスワードの「root」を入力 ターミナル root [Enterキー] c9というデータベースを作成 ターミナル create database c9; うまく作成されたか確認 ターミナル show databases; 下記のようにtarminalに表示されれば成功 データベースから退場 ターミナル exit; Laravelプロジェクト初期設定 .envファイルの更新 上記のように「Show Hidden Files」を設定し.envファイルが確認 .envファイルの下記該当部分を内容を下記のように更新し保存 .env DB_CONNECTION=mysql DB_HOST=localhost DB_PORT=3306 DB_DATABASE=c9 DB_USERNAME=root DB_PASSWORD=root Composerアップデートコマンド実行 更新内容を反映するために、サーバーを一度停止。 サーバーを動かしているtarminalで"control+c"を入力し、サーバーを停止。 その後下記を入力し、composerをupdate。 ターミナル sudo composer update 途中で質問が出るが、yesで回答。 その後、再度サーバーを起動。 ターミナル $ php artisan serve --port=8080 /app/Providers/ AppServiceProvider.php ファイルを修正 app→Providers→AppServiceProvider.phpと進み、下記のように記載。 AppServiceProvider.php <?php namespace App\Providers; use Illuminate\Support\ServiceProvider; use Illuminate\Support\Facades\Schema; //この行を追加 use Illuminate\Support\Facades\URL; //この行を追加 class AppServiceProvider extends ServiceProvider { /** * Register any application services. * * @return void */ public function register() { // } /** * Bootstrap any application services. * * @return void */ public function boot() { Schema::defaultStringLength(191); //この行を追加 URL::forceScheme('https'); //この行を追加 } } phpMyAdmin設定 cms階層からpublicフォルダに移動 $ cd public phpMyAdminのzipをダウンロード $ wget https://files.phpmyadmin.net/phpMyAdmin/4.8.3/phpMyAdmin-4.8.3-all-languages.zip zipファイルを解凍 $ unzip phpMyAdmin-4.8.3-all-languages.zip cms階層に戻る $ cd .. phpMyAdminを確認する publicフォルダ内に「phpMyAdmin-4.8.3-all-languages」フォルダが作成される。 フォルダ名が長いので「phpMyAdmin」に変更。 「Preview」で開かれているURLの最後に「phpMyAdmin/index.php」をつけてEnterキーを押す。 ＊　URL例： https://＊＊＊＊＊＊.cloud9.us-east-1.amazonaws.com/phpMyAdmin/index.php phpMyAdmin画面が表示されたら： ユーザー名・パスワードともに「root」を入力してログイン ログインできればOK お気に入りYouTube管理アプリを実装する 以下のコマンドは作業ディレクトリのcmsで行ってください。 Laravel/uiの実装 今後のUIを整えるために必要なパッケージをインストールします。 インストールできると、ログイン認証画面が簡単に実装できます。 1. マイグレーションを実行 php artisan migrate 2. laravel/ui パッケージをインストール composer require laravel/ui:^1.0 --dev 3. artisan コマンドを実行 php artisan ui vue --auth 4. npmパッケージをインストール npm install 5. パッケージをビルド npm run dev 右上にログインが表示されれば、成功です。 データベースにMoviesテーブルを作成する為のマイグレーションを作成 1. artisanコマンドでマイグレーション作成 ターミナル $ php artisan make:migration create_movies_table --create=movies 2. database/migrationsの直下のmovies_table.phpに以下追記 movies_table.php public function up() { Schema::create('movies', function (Blueprint $table) { $table->bigIncrements('id'); $table->string('item_name'); $table->text('item_url'); $table->timestamps(); }); } 3. マイグレーション実行（テーブルの作成） ターミナル php artisan migrate phpMyAdminでmoviesが作成されているか確認する カラムの修正・追加時は、tableのファイルを修正・保存後に、下記コマンドでrefreshする。 ターミナル $ php artisan migrate:refresh モデルの作成/ルーティングとviewの設定 1.artisanコマンドでモデル作成 作成したテーブルを適宜使用するためにモデルを作成します。 このモデルに対して働きかけることで、テーブルの管理を行います。 その際に、複数形のテーブル名を単数形＋大文字スタートでモデル名を設定すれば、Laravel上で自動的にリンクされます。 ターミナル $ php artisan make:model Movie 2./routes/web.phpの設定 web.phpはこのプロジェクトの設計図にあたる場所で、このプロジェクトで使用するURLを管理する場所です。 このファイルを見れば、このプロジェクトがどのように作成されているかを理解できる場所です。 まず、このweb.phpと先ほど作成したMovieモデルを接続します。 また、後ほど作成するコントローラーに機能を振り分けるための処理を記載します。 web.php <?php use App\Movie; use Illuminate\Http\Request; /* |-------------------------------------------------------------------------- | Web Routes |-------------------------------------------------------------------------- | | Here is where you can register web routes for your application. These | routes are loaded by the RouteServiceProvider within a group which | contains the "web" middleware group. Now create something great! | */ // 動画管理の初期画面 Route::get('/', 'MoviesController@index'); // 新「動画」を追加 Route::post('/movies', 'MoviesController@store'); // 動画を削除 Route::delete('/movie/{movie}', 'MoviesController@destroy'); //「動画」を更新画面表示 Route::get('/moviesedit/{movie}','MoviesController@edit'); //「動画」を更新処理 Route::post('movies/update','MoviesController@update'); Auth::routes(); Route::get('/home', 'HomeController@index')->name('home'); Auth::routes(); Route::get('/home', 'HomeController@index')->name('home'); 4. MoviesControllerの設定。 app->Http->Controllers->MoviesController.phpに下記を追記します。 MoviesController.php <?php namespace App\Http\Controllers; use Illuminate\Http\Request; use App\Movie; use Validator; class MoviesController extends Controller { /** * Display a listing of the resource. * * @return \Illuminate\Http\Response */ public function index() { $movies = Movie::orderBy('created_at', 'asc')->paginate(3); return view('movies', [ 'movies' => $movies ]); } /** * Show the form for creating a new resource. * * @return \Illuminate\Http\Response */ public function create() { // } /** * Store a newly created resource in storage. * * @param \Illuminate\Http\Request $request * @return \Illuminate\Http\Response */ public function store(Request $request) { //バリデーション $validator = Validator::make($request->all(), [ 'item_name' => 'required|max:255', ]); //バリデーション:エラー if ($validator->fails()) { return redirect('/') ->withInput() ->withErrors($validator); } //以下に登録処理を記述（Eloquentモデル） // Eloquent モデル $movies = new Movie; $movies->item_name = $request->item_name; $movies->item_url = $request->item_url; $movies->save(); return redirect('/'); } /** * Display the specified resource. * * @param int $id * @return \Illuminate\Http\Response */ public function show($id) { // } /** * Show the form for editing the specified resource. * * @param int $id * @return \Illuminate\Http\Response */ public function edit(Movie $movie) { return view('moviesedit', ['movie' => $movie]); } /** * Update the specified resource in storage. * * @param \Illuminate\Http\Request $request * @param int $id * @return \Illuminate\Http\Response */ public function update(Request $request) { //バリデーション $validator = Validator::make($request->all(), [ 'item_name' => 'required|max:255', ]); //バリデーション:エラー if ($validator->fails()) { return redirect('/') ->withInput() ->withErrors($validator); } // Eloquent モデル $movies = Movie::find($request->id); $movies->item_name = $request->item_name; $movies->item_url = $request->item_url; $movies->save(); return redirect('/'); } /** * Remove the specified resource from storage. * * @param int $id * @return \Illuminate\Http\Response */ public function destroy(Movie $movie) { $movie->delete(); //追加 return redirect('/'); //追加 } } 5. resources/views/の直下にmovies.blade.php を作成して以下を追記 動画を登録するためのUIとなるページを作成します。 UI部分はこのviewsファイルに格納します。 movies.blade.php <!-- resources/views/movies.blade.php --> @extends('layouts.app') @section('content') <!-- Bootstrapの定形コード… --> <div class="card-body"> <div class="card-title"> ＜お気に入り動画入力フォーム＞ </div> <!-- バリデーションエラーの表示に使用--> @include('common.errors') <!-- バリデーションエラーの表示に使用--> <!-- 動画登録フォーム --> <form action="{{ url('movies') }}" method="POST" class="form-horizontal"> {{ csrf_field() }} <!-- 動画のタイトル --> <div class="form-group"> <div class="card-title"> ＜動画タイトル＞ </div> <div class="col-sm-6"> <input type="text" name="item_name" class="form-control"> </div> </div> <!-- 動画のURL --> <div class="form-group"> <div class="card-title"> ＜動画URL＞ </div> <div class="col-sm-6"> <input type="text" name="item_url" class="form-control"> </div> </div> <!-- 動画 登録ボタン --> <div class="form-group"> <div class="col-sm-offset-3 col-sm-6"> <button type="submit" class="btn btn-primary"> Save </button> </div> </div> </form> <!-- 現在の動画 --> @if (count($movies) > 0) <div class="card-body"> <div class="card-body"> <table class="table table-striped task-table"> <!-- テーブルヘッダ --> <thead> <th>動画タイトル</th> <th>動画URL</th> <th>&nbsp;</th> <th>&nbsp;</th> <th>&nbsp;</th> </thead> <!-- テーブル動画体 --> <tbody> @foreach ($movies as $movie) <tr> <!-- 動画タイトル --> <td class="table-text"> <div>{{ $movie->item_name }}</div> </td> <!-- 動画URL --> <td class="table-text"> <div>{{ $movie->item_url }}</div> </td> <td class="table-text"> <button type=“submit” class="btn btn-success" onclick="location.href='{{$movie->item_url}}'">動画へ</button> </td> <!-- 動画: 削除ボタン --> <td> <form action="{{ url('moviesedit/'.$movie->id) }}" method="GET"> {{ csrf_field() }} <button type="submit" class="btn btn-primary">更新 </button> </form> </td> <td> <form action="{{ url('movie/'.$movie->id) }}" method="POST"> <form action="{{ url('movie/'.$movie->id) }}" method="POST"> {{ csrf_field() }} {{ method_field('DELETE') }} <button type="submit" class="btn btn-danger"> 削除 </button> </form> </td> </tr> @endforeach </tbody> </table> </div> </div> @endif <!-- Movie: 既に登録されてる動画のリスト --> <div class="row"> <div class="col-md-4 offset-md-4"> {{ $movies->links()}} </div> </div> @endsection 6. resources/views/の直下にmoviesedit.blade.php を作成して以下を追記 動画の内容を変更し登録するためのUIとなるページを作成します。 moviesedit.blade.php @extends('layouts.app') @section('content') <div class="row"> <div class="col-md-12"> @include('common.errors') <form action="{{ url('movies/update') }}" method="POST"> <!-- item_name --> <div class="form-group"> <label for="item_name">Title</label> <input type="text" name="item_name" class="form-control" value="{{$movie->item_name}}"> </div> <!--/ item_name --> <!-- Save ボタン/Back ボタン --> <div class="well well-sm"> <button type="submit" class="btn btn-primary">Save</button> <a class="btn btn-link pull-right" href="{{ url('/') }}"> Back</a> </div> <!--/ Save ボタン/Back ボタン --> <!-- id 値を送信 --> <input type="hidden" name="id" value="{{$movie->id}}" /> <!--/ id 値を送信 --> <!-- CSRF --> {{ csrf_field() }} <!--/ CSRF --> </form> </div> </div> @endsection 7. /resources/views/common/errors.blade.phpを作成し以下を追記 誤った入力が行われた場合の処理を設定するために、commonフォルダを作成し、errors.blade.phpファイルを作成します。 errors.blade.php @if (count($errors) > 0) <!-- Form Error List --> <div class="alert alert-danger"> <div><strong>入力した文字を修正してください。</strong></div> <div> <ul> @foreach ($errors->all() as $error) <li>{{ $error }}</li> @endforeach </ul> </div> </div> @endif データベース管理の設定について データベースは、 ① 登録 ② 表示 ③ 更新 ④ 削除 の4つ機能で全て表現することができます。 そしてこれらの処理については、MoviesController.phpに記載されています。 登録について web.phpの中も「動画の追加部分」に'MoviesController@store'と記載することで、登録処理についてはMoviesController.php内のstore部分で行うように振り分けることができます。 MoviesController.php public function store(Request $request) { //バリデーション $validator = Validator::make($request->all(), [ 'item_name' => 'required|max:255', ]); //バリデーション:エラー if ($validator->fails()) { return redirect('/') ->withInput() ->withErrors($validator); } //以下に登録処理を記述 $movies = new Movie; $movies->item_name = $request->item_name; $movies->item_url = 'aaaa'; $movies->item_details = 'details'; $movies->published = '2017-03-07 00:00:00'; $movies->save(); return redirect('/'); } 表示について web.phpの中も「動画管理の初期画面」に'MoviesController@index'と記載することで、表示についてはMoviesController.php内のindex部分で行うように振り分けることができます。 MoviesController.php public function index() { $movies = Movie::orderBy('created_at', 'asc')->paginate(3); return view('movies', [ 'movies' => $movies ]); } これにより、Movieモデルを介して、moviesテーブル内のデータが降順に$moviesに格納され、viewファイル内のmovies.blade.phpにデータが渡されます。 更新について web.phpの中も「更新画面表示」にからMoviesedit.phpに遷移し、中の処理は'MoviesController@edit'と記載することで、MoviesController.php内のedit部分で行うように振り分けることができます。 MoviesController.php public function index() { $movies = Movie::orderBy('created_at', 'asc')->paginate(3); return view('movies', [ 'movies' => $movies ]); } その後、updateにて更新された内容が反映されます。 削除処理について web.phpの中の「削除」部分にあるdeleteの中に、選択された項目のidを持った変数が選択され、それが削除されるという処理をMoviesController.php内のdestoryに振り分けるという記述を行いっています。 MoviesController.php public function destroy(Movie $movie) { $movie->delete(); //追加 return redirect('/'); //追加 } 長々と書きましたが、これで下記のようなものが実装完成です。

Amazon Redshift | Databricks on AWS [2021/3/17時点]の翻訳です。 Apache Spark SQLデータフレームにデータを読み込むデータソースとしてAmazon Redshiftを利用できますし、Redshiftのテーブルに書き込むことも可能です。Redshiftデータソースは、効率的にデータを転送するためにAmazon S3を使用し、自動的にRedshift上で適切にCOPY、UNLOADを実行するためにJDBCを使用します。 Redshiftデータソースは、クエリの都度S3に対して大量のデータを出力するので、インタラクティブなクエリよりもバッチワークロードに適しています。Redshift上の同じデータに対して繰り返しクエリーを実行するのであれば、抽出したデータをApache Parquetなどの最適化されたフォーマットで保存することをお勧めします。 注意 DatabricksのVPCにおけるセキュリティモデルによる権限の問題が生じる場合があるため、RedshiftのクラスターはDatabricks管理のVPCの中に作るべきではありません。ご自身のVPCの中にRedshiftクラスターを作成し、DatabricksからRedshiftインスタンスに接続するためにVPC peeringを実施してください。 インストール DatabricksランタイムにはAmazon Redshiftデータソースが含まれています。追加のインストールは不要です。Databricksランタイムリリースに含まれるRedshiftデータソースのバージョンを確認するには、Databricksランタイムのリリースノートを確認ください。 Redshiftデータソースには、Redshiftと互換性のあるJDBCドライバーが必要となります。RedshiftはPostgreSQLデータベースシステムに基づいているので、Databricksランタイムに含まれているPostgreSQLのJDBCドライバーか、Amazonが推奨するRedshiftのJDBCドライバーを使用することができます。PostgreSQLのJDBCドライバーを使う場合にはインストールは不要です。リリースに含まれるPostgreSQL JDBCドライバーのバージョンはリリースノートを確認できます。 RedshiftのJDBCドライバーを使う際には、手動でのインストールが必要となります。Redshiftドライバーは、postgresqlとredshiftのJDBC接続の両方のハンドラーとして自身を登録しています。クラスター上でRedshiftとPostgreSQL両方と連携すると競合が発生する可能性があります。このため、DatabricksはRedshiftのJDBCドライバーをバンドルしていません。詳細に関しては、Stack Overflowのポストを参考にしてください。RedshiftのJDBCドライバーをバンドルすると、JDBC 4.0、4.1、4.2バージョンを選択することができなくなります。 RedshiftのJDBCドライバーを手動でインストールするには： Amazonからドライバーをダウンロードします。 ドライバーをDatabricksワークスペースにアップロードします。 クラスターにライブラリをインストールします。 注意 Redshift JDBCドライバーv1.2.16には、SQLクエリーにwhere句を指定した際に空のデータが返却される問題があります。最新のドライバーを使用することをお勧めします。 使用法 ドライバーに応じて、JDBC URLを設定します。 バンドルされているPostgreSQL JDBCドライバー： jdbc:postgresql://... Redshift JDBCドライバー： jdbc:redshift://... 以下のサンプルはRedshiftドライバーを使用した例です。PostgreSQL JDBCドライバーを使用する際にはurlを置き換えてください。 AWSの認証情報を設定することで、Python、SQL、R、Scalaで提供されているSparkデータソースAPI経由で、データソースにアクセスできるようになります。 Python # Read data from a table df = spark.read \ .format("com.databricks.spark.redshift") \ .option("url", "jdbc:redshift://<the-rest-of-the-connection-string>") \ .option("dbtable", "<your-table-name>") \ .option("tempdir", "s3a://<your-bucket>/<your-directory-path>") \ .load() # Read data from a query df = spark.read \ .format("com.databricks.spark.redshift") \ .option("url", "jdbc:redshift://<the-rest-of-the-connection-string>") \ .option("query", "select x, count(*) <your-table-name> group by x") \ .option("tempdir", "s3a://<your-bucket>/<your-directory-path>") \ .load() # After you have applied transformations to the data, you can use # the data source API to write the data back to another table # Write back to a table df.write \ .format("com.databricks.spark.redshift") \ .option("url", "jdbc:redshift://<the-rest-of-the-connection-string>") \ .option("dbtable", "<your-table-name>") \ .option("tempdir", "s3a://<your-bucket>/<your-directory-path>") \ .mode("error") \ .save() # Write back to a table using IAM Role based authentication df.write \ .format("com.databricks.spark.redshift") \ .option("url", "jdbc:redshift://<the-rest-of-the-connection-string>") \ .option("dbtable", "<your-table-name>") \ .option("tempdir", "s3a://<your-bucket>/<your-directory-path>") \ .option("aws_iam_role", "arn:aws:iam::123456789000:role/redshift_iam_role") \ .mode("error") \ .save() SQL SQLによるデータ読み込み CREATE TABLE example_table USING com.databricks.spark.redshift OPTIONS ( dbtable '<your-table-name>', tempdir 's3a://<your-bucket>/<your-directory-path>', url 'jdbc:redshift://<the-rest-of-the-connection-string>' ); SQLによるデータ書き込み -- Create a new table, throwing an error if a table with the same name already exists CREATE TABLE example_table USING com.databricks.spark.redshift OPTIONS ( dbtable '<your-table-name>', tempdir 's3a://<your-bucket>/<your-directory-path>' url 'jdbc:redshift://<the-rest-of-the-connection-string>' ) AS SELECT * FROM table_to_save; R Rによるデータ読み込み df <- read.df( NULL, "com.databricks.spark.redshift", tempdir = "s3a://<your-bucket>/<your-directory-path>", dbtable = "<your-table-name>", url = "jdbc:redshift://<the-rest-of-the-connection-string>") Scala // Get some data from a Redshift table val df: DataFrame = spark.read .format("com.databricks.spark.redshift") .option("url", "jdbc:redshift://<the-rest-of-the-connection-string>") .option("dbtable", "<your-table-name>") .option("tempdir", "s3a://<your-bucket>/<your-directory-path>") .load() // Also load data from a Redshift query val df: DataFrame = spark.read .format("com.databricks.spark.redshift") .option("url", "jdbc:redshift://<the-rest-of-the-connection-string>") .option("query", "select x, count(*) <your-table-name> group by x") .option("tempdir", "s3a://<your-bucket>/<your-directory-path>") .load() // After you have applied transformations to the data, you can use // the data source API to write the data back to another table // Write back to a table df.write .format("com.databricks.spark.redshift") .option("url", "jdbc:redshift://<the-rest-of-the-connection-string>") .option("dbtable", "<your-table-name>") .option("tempdir", "s3a://<your-bucket>/<your-directory-path>") .mode("error") .save() // Write back to a table using IAM Role based authentication df.write .format("com.databricks.spark.redshift") .option("url", "jdbc:redshift://<the-rest-of-the-connection-string>") .option("dbtable", "<your-table-name>") .option("aws_iam_role", "arn:aws:iam::123456789000:role/redshift_iam_role") .option("tempdir", "s3a://<your-bucket>/<your-directory-path>") .mode("error") .save() 設定 S3とRedshiftの認証 以下の図に示すように、データソースにはいくつかのネットワーク接続が関係します。 ┌───────┐ ┌───────────────────>│ S3 │<─────────────────┐ │ IAM or keys └───────┘ IAM or keys │ │ ^ │ │ │ IAM or keys │ v v ┌──────v────┐ ┌────────────┐ ┌───────────┐ │┌──────────┴┐ │ Redshift │ │ Spark │ ││ Spark │ │ │<──────────>│ Driver │<────────>| Executors │ └────────────┘ └───────────┘ └───────────┘ JDBC with Configured username / in password Spark (SSL enabled by default) Redshiftとデータをやり取りする際には、データソースはS3にデータを書き込みます。そのため、S3バケット(tempdir設定パラメータで指定します)に対する読み書きのための認証情報が必要となります。 注意 データソースは、S3に生成される一時ファイルをクリーンアップしません。このため、一定期間後にオブジェクトを自動で削除するように、オブジェクトライフサイクル設定を伴う専用のS3バケットを使用することをお勧めします。どのようにファイルを暗号化するかに関しては、本ドキュメントの暗号化を参照ください。 以下のセクションではそれぞれの接続における認証設定を説明します。 SparkのドライバーノードからRedshiftへの接続 SparkからS3への接続 RedshiftからS3への接続 SparkのドライバーノードからRedshiftへの接続 Sparkドライバーノードは、usernameとpasswordを用いて、JDBC経由でRedshiftに接続します。Redshiftは接続を認証するためのIAMロールの使用をサポートしていません。デフォルトでは、接続はSSL暗号化されます。詳細は暗号化を参照ください。 SparkからS3への接続 Redshiftに対する読み書きを行う際、S3は大量データの仲介役として動作します。Sparkは、HadoopファイルシステムインタフェースとAmazon Java SDKのS3クライアントの両方を使用してS3にアクセスします。この接続はAWSのキーあるいはインスタンスプロファイル(DBFSマウントポイントはサポートされていないので、AWSキーを使いたくない場合には、クラスターのインスタンスプロファイルを使用する必要があります)。認証情報を渡すためには4つの方法があります。 デフォルトのクレディンシャルプロバイダーチェーン(多くのケースでベストな選択肢となります): AWSの認証情報はDefaultAWSCredentialsProviderChainを通じて自動的に収集されます。S3への認証を行う際にインスタンスプロファイルを使用している際には、多くの場合にこの方法を使用することになります。 Hadoop設定にキーをセットする: Hadoop configuration propertiesを使用してAWSキーを設定することができます。tempdirの設定でs3a://ファイルシステムをポイントしているのであれば、HadoopのXML設定ファイルにfs.s3a.access.keyとfs.s3a.secret.keyプロパティを設定するか、sc.hadoopConfiguration.set()を呼び出してSparkのグローバルHadoop設定にキーをセットすることができます。s3n://ファイルシステムを使用している場合は、以下の例に示すようにレガシーな設定キーを指定することができます。 Scala s3aファイルシステムを使用している場合は、以下を追加します。 sc.hadoopConfiguration.set("fs.s3a.access.key", "<your-access-key-id>") sc.hadoopConfiguration.set("fs.s3a.secret.key", "<your-secret-key>") レガシーなs3nファイルシステムを使用している場合には、以下を追加します。 sc.hadoopConfiguration.set("fs.s3n.awsAccessKeyId", "<your-access-key-id>") sc.hadoopConfiguration.set("fs.s3n.awsSecretAccessKey", "<your-secret-key>") Python 以下のコマンドはSparkの内部処理に依存している部分がありますが、PySparkでも動作するはずで、将来的に振る舞いが変更される可能性は低いです。 sc._jsc.hadoopConfiguration().set("fs.s3a.access.key", "<your-access-key-id>") sc._jsc.hadoopConfiguration().set("fs.s3a.secret.key", "<your-secret-key>") IAMロールを前提とする: インスタンスプロファイルが使用するIAMロールを使用することもできます。ロールのARNを指定するためには、インスタンスプロファイルをクラスターにアタッチし、以下の設定キーを提供する必要があります。 Scala sc.hadoopConfiguration.set("fs.s3a.credentialsType", "AssumeRole") sc.hadoopConfiguration.set("fs.s3a.stsAssumeRole.arn", <iam-role-arn-to-be-assumed>) Python sc._jsc.hadoopConfiguration().set("fs.s3a.credentialsType", "AssumeRole") sc._jsc.hadoopConfiguration().set("fs.s3a.stsAssumeRole.arn", <iam-role-arn-to-be-assumed>) RedshiftからS3への接続 また、RedshiftもCOPY、UNLOADクエリーの際にはS3にアクセスします。この接続の際には3つの方法で認証を行うことができます： IAMロールを前提とする（最もセキュアです）: COPY、UNLOADの際、RedshiftにIAMロールを許可することができ、Redshiftがそのロールを使用するようにデータソースを設定できます。 バケットにアクセスできるS3権限をIAMロールに許可する Authorizing Amazon Redshift to Access Other AWS Services On Your Behalfのガイドに従って、Redshiftがこのロールを使用できるようにロールの信頼ポリシーを設定する Authorizing COPY and UNLOAD Operations Using IAM Rolesのガイドに従い、IAMロールとRedshiftクラスターを関連づける SparkのS3認証情報をRedshiftに転送する: forward_spark_s3_credentialsオプションがtrueに設定されているのであれば、データソースは自動的にSparkが使用している認証情報を検知し、JDBC経由でRedshiftに転送します。Sparkがインスタンスプロファイルを使用してS3にアクセスしているのであれば、テンポラリーSTS認証情報のセットがRedshiftに転送されます。そうでなければ、AWSキーが転送されます。JDBCのクエリーにこれらの認証情報が埋め込まれるので、この認証方式を使用する際には、必ずJDBC接続におけるSSL暗号化を有効化してください。 セキュリティトークンサービス(STS)を使用する: AWSのSecurity Token Serviceで生成される一時的なキーを使用するためにtemporary_aws_access_key_id、temporary_aws_secret_access_key、 temporary_aws_session_tokenを設定することも可能です。JDBCのクエリーにこれらの認証情報が埋め込まれるので、この認証方式を使用する際には、必ずJDBC接続におけるSSL暗号化を有効化してください。この方式を選択した際には、読み書きの操作が成功する前に、認証情報が期限切れになる可能性があることに注意してください。 これら3つのオプションを組み合わせることはできないので、必ず明示的にどれか一つを選択する必要があります。 暗号化 JDBCをセキュアにする: JDBC URLにSSLに関連する設定が存在しない場合、デフォルトでデータソースはSSL暗号化を有効にし、Redshiftサーバーが信頼できるか(sslmode=verify-fullかどうか)を検証します。このため、初回はAmazonサーバーから自動でサーバー証明書がダウンロードされます。これに失敗した場合は、フォールバックとして事前にバンドルされている証明書が使用されます。これは、Redshift、PostgreSQLドライバー両方に適用されます。SSLの自動設定は、2.1.1-db4 cluster image (未サポート)で導入されました。これより前のリリースでは、SSLは自動で設定されず、デフォルトのJDBC設定(SSL無効)が使用されます。 この機能において不具合が生じた場合、あるいはSSLを無効化したい場合には、自身のコードにおけるDataFrameReaderあるいはDataFrameWriterで.option("autoenablessl", "false")オプションを設定することができます。 カスタムのSSL設定を適用したい場合には、Redshiftのドキュンメント、Using SSL and Server Certificates in Java、JDBC Driver Configuration Optionsの手順に従ってください。JDBC urlに記載されたSSL関連の設定は優先されます。つまり、自動設定は停止します。 S3に格納されたUNLOADデータを暗号化する（Redshiftから読み込みを行なった際に格納されるデータ）: Redshiftのドキュメント、Unloading Data to S3によれば、「UNLOADはAmazon S3のサーバーサイド暗号化(SSE-S3)によってデータを暗号化します」とあります。 また、Redshiftはクライアントサイドのカスタムキーによる暗号化(Unloading Encrypted Data Filesを参照ください)もサポートしていますが、データソースには要求されるシンメトリックキーを指定する機能を有していません。 S3に格納されたCOPYデータを暗号化する(Redshiftに書き込みを行う際に格納されるデータ): Redshiftドキュメント、Loading Encrypted Data Files from Amazon S3には以下の記載があります。 AWSが管理する暗号化キーによるサーバーサイド暗号化(SSE-S3、SSE-KMS)、あるいはクライアントサイド暗号化、これらの両方を用いて、Amazon S3にアップロードされたデータファイルをロードするのにCOPYコマンドを使用することができます。COPYは、顧客管理のキーによるAmazon S3サーバーサイド暗号化(SSE-C)をサポートしていません。 この機能を使う際には、お使いのHadoop S3ファイルシステムがAmazon S3 encryptionを使うように設定してください。この際、書き込まれるファイルの一覧を含むMANIFESTファイルは暗号化されません。 パラメーター Spark SQLで提供されるパラメーターマップ、OPTIONSは以下の通りです。 原文を参照ください。 追加の設定オプション 文字列カラムの最大サイズの設定 Redshiftのテーブルを作成する際、デフォルトの振る舞いにおいては、文字列のカラムはTEXTカラムとなります。RedshiftはTEXTカラムをVARCHAR(256)として格納しますので、この列は最大256文字となります(ソース)。 よりサイズの大きいカラムにするためには、それぞれの文字列のカラムの最大長を指定するためのカラムメタデータフィールドmaxlengthを使用できます。これは、デフォルトより小さいサイズのカラムを宣言することで、容量を節約し、パフォーマンスの改善を行う際にも有効です。 注意 Sparkの制限のため、SQLとRのAPIでは、カラムメタデータ変更はサポートされていません。 Python df = ... # the dataframe you'll want to write to Redshift # Specify the custom width of each column columnLengthMap = { "language_code": 2, "country_code": 2, "url": 2083, } # Apply each column metadata customization for (colName, length) in columnLengthMap.iteritems(): metadata = {'maxlength': length} df = df.withColumn(colName, df[colName].alias(colName, metadata=metadata)) df.write \ .format("com.databricks.spark.redshift") \ .option("url", jdbcURL) \ .option("tempdir", s3TempDirectory) \ .option("dbtable", sessionTable) \ .save() Scala 以下のサンプルは、Spark Scala APIを用いて複数のカラムのメタデータを更新するものです。 import org.apache.spark.sql.types.MetadataBuilder // Specify the custom width of each column val columnLengthMap = Map( "language_code" -> 2, "country_code" -> 2, "url" -> 2083 ) var df = ... // the dataframe you'll want to write to Redshift // Apply each column metadata customization columnLengthMap.foreach { case (colName, length) => val metadata = new MetadataBuilder().putLong("maxlength", length).build() df = df.withColumn(colName, df(colName).as(colName, metadata)) } df.write .format("com.databricks.spark.redshift") .option("url", jdbcURL) .option("tempdir", s3TempDirectory) .option("dbtable", sessionTable) .save() カスタムカラムタイプの設定 手動でカラムタイプを設定する際には、redshift_typeカラムメタデータを使用します。例えば、Spark SQL Schema -> Redshift SQLのタイプマッピングを上書きして、ユーザー定義のカラムタイプを指定したい場合には、以下のようにします。 Python # Specify the custom type of each column columnTypeMap = { "language_code": "CHAR(2)", "country_code": "CHAR(2)", "url": "BPCHAR(111)", } df = ... # the dataframe you'll want to write to Redshift # Apply each column metadata customization for (colName, colType) in columnTypeMap.iteritems(): metadata = {'redshift_type': colType} df = df.withColumn(colName, df[colName].alias(colName, metadata=metadata)) Scala import org.apache.spark.sql.types.MetadataBuilder // Specify the custom type of each column val columnTypeMap = Map( "language_code" -> "CHAR(2)", "country_code" -> "CHAR(2)", "url" -> "BPCHAR(111)" ) var df = ... // the dataframe you'll want to write to Redshift // Apply each column metadata customization columnTypeMap.foreach { case (colName, colType) => val metadata = new MetadataBuilder().putString("redshift_type", colType).build() df = df.withColumn(colName, df(colName).as(colName, metadata)) } カラムのエンコーディングの設定 テーブルを作成する際に、カラムごとにカラムメタデータフィールドencodingを指定します。(利用可能なエンコーディングに関してはAmazonのドキュメントを参照ください) カラムの説明の設定 Redshiftでは、カラムに対する説明を追加することができ、一般的なクエリーツールで(COMMENTコマンドを利用して)参照することができます。カラムメタデータフィールドdescriptionでカラムごとの説明を指定できます。 Redshiftへのクエリープッシュダウン Sparkオプティマイザーは、以下のオペレーターをRedshiftにプッシュダウンします。 Filter Project Sort Limit Aggregation Join ProjectとFilterにおいては、以下の表現をサポートしています。 ほとんどのブーリアンオペレーター 比較 基本的な算術処理 数字、文字列のキャスト ほとんどの文字列関数 全体をRedshiftにプッシュダウンできる場合は、スカラーのサブクエリ 注意 プッシュダウンは、日付とタイムスタンプを操作する表現はサポートしていません。 Aggregationにおいては、以下の集約関数をサポートしています。 AVG COUNT MAX MIN SUM STDDEV_SAMP STDDEV_POP VAR_SAMP VAR_POP 利用できる場合には、DISTINCT句と組み合わせることができます。 Joinにおいては、以下のジョインをサポートしています。 INNER JOIN LEFT OUTER JOIN RIGHT OUTER JOIN LEFT SEMI JOIN LEFT ANTI JOIN オプティマイザーによってJoinに書き込まれるサブクエリ。例： WHERE EXISTS、WHERE NOT EXISTS 注意 Joinのプッシュダウンは、FULL OUTER JOINをサポートしていません。 LIMITを使うクエリーにおいて、プッシュダウンが最も有効かもしれません。SELECT * FROM large_redshift_table LIMIT 10のようなクエリーは、中間データとしてテーブル全体をS3にUNLOADするため、非常に時間がかかる場合があります。プッシュダウンを活用することで、LIMITはRedshiftで実行されます。集計を伴うクエリーにおいては、集計処理をRedshiftにプッシュダウンすることで、転送されるデータ量を削減することが可能になります。 Redshiftへのクエリープッシュダウンはデフォルトで有効になっています。spark.databricks.redshift.pushdownをfalseに設定することで無効化することができます。無効化されている場合においても、Sparkはフィルターとカラムの削除はRedshiftにプッシュダウンします。 トランザクションの保証 本章では、Sparkに対するRedshiftデータソースのトランザクション保証を説明します。 RedshiftとS3の特性のバックグラウンド Redshiftのトランザクション保証に関する一般的な情報に関しては、RedshiftドキュメントのManaging Concurrent Write Operationsを参照してください。要約すると、RedshiftのBEGINコマンドのドキュメントによれば、Redshiftはserializable isolationを提供しています。 4つのトランザクションレベルのいずれも使用できますが、Amazon Redshiftはすべての分離レベルをシリアライズ可能として処理します。 Redshiftドキュメントによれば、 Amazon Redshiftは、それぞれ実行されたSQLコマンドを個別にコミットする自動コミットをデフォルトでサポートしています。 すなわち、COPYやUNLOADのような個々のコマンドは原子的、かつトランザクションが保証されます。一方、複数のコマンドやクエリーの原子性を保証するときには、明示的なBEGINとENDが必要になります。 Redshiftに読み書きを行う際、データソースはS3に読み書きを行います。SparkとRedshiftは部分的な出力を生成し、複数のファイルとしてS3に格納します。Amazon S3 Data Consistency Modelによると、S3バケットの一覧操作は結果的整合性を保証しています。このため、データソースの結果的整合性によるデータの欠損や欠如を避けるためにこれらのファイルは、特定のサイズに到達する必要があります。 Sparkに対するRedshiftデータソースの保証 既存テーブルへの追加 Redshiftに行を追加する際、データソースはCOPYコマンドを使用し、結果的整合性のS3操作に備えるためにmanifestsを指定します。結果として、spark-redshiftは、通常のRedshiftのCOPYコマンドと同じ原子性、トランザクション特性を持つ既存テーブルに追加を行います。 新規テーブルの作成(SaveMode.CreateIfNotExists) テーブルの作成は、CREATE TABLEコマンド、および初期のレコードを追加するCOPYコマンドから構成される二段階のプロセスとなります。両方の操作は同一のトランザクションとして実行されます。 既存テーブルの上書き デフォルトでは、対象テーブルの削除、空テーブルの新規作成、行追加から構成されるトランザクションで上書きを行います。 usestagingtableがfalseに設定されている場合、上書き操作の原子性を犠牲にしてRedshiftでの上書きに必要なステージング領域を削減できるように、データソースは新規テーブルに行を追加する前に、DELETE TABLEコマンドをコミットします。 Redshiftテーブルへのクエリー クエリーにおいては、RedshiftのUNLOADコマンドを使用し、結果をS3に保存し、S3の結果的整合性の操作に備えるためにmanifestsを使用します。結果として、SparkのRedshiftデータソースからのクエリーは、通常のRedshiftクエリーと同様の一貫性を持ちます。 一般的な問題及び解決策 S3バケットとRedshitクラスターが異なるAWSリージョンに存在する デフォルトでは、S3バケットとRedshiftクラスターが異なるAWSリージョンに存在している場合にはS3 <-> Redshiftのコピーは動作しません。 異なるリージョンにS3バケットがあるケースで、Redshiftのテーブルから読み取りを行おうとすると、以下のようなエラーが発生します。 ERROR: S3ServiceException:The S3 bucket addressed by the query is in a different region from this cluster.,Status 301,Error PermanentRedirect. 同様のケースで書き込みを行おうとすると、以下のようなエラーが発生します。 error: Problem reading manifest file - S3ServiceException:The S3 bucket addressed by the query is in a different region from this cluster.,Status 301,Error PermanentRedirect 書き込み: RedshiftのCOPYコマンドでは、明示的にS3バケットのリージョンを指定することができますので、このケースにおいてはextracopyoptionsにregion 'the-region-name'を追加することで、Redshiftが適切に動作するようになります。例えば、バケットがUS East (Virginia)にある場合には、Scala APIでは以下のように指定します。 Scala .option("extracopyoptions", "region 'us-east-1'") Databricksランタイム6.2以降では、代わりにawsregionを使用することも可能です。 Scala .option("awsregion", "us-east-1") 読み取り: RedshiftのUNLOADコマンドでもS3バケットのリージョンを指定できます。Databricksランタイム6.2以降ではawsregionを設定することで、正常に読み取りを行えるようになります。 Scala .option("awsregion", "us-east-1") Databricksランタイム6.1以前では、データソースは異なるリージョンのバケットへの書き込みをサポートしていません。唯一のワークアラウンドは、Redshiftと同じリージョンに新たなバケットを作成することです。 S3の認証を行う際にインスタンスプロファイルを使用した場合に、予期しないS3ServiceException credentials errorが発生する S3の認証を行う際にインスタンスプロファイルを使用していて、予期しないS3ServiceExceptionエラーに直面した際には、S3 URIのtempdir、Hadoopの設定、あるいはDefaultAWSCredentialsProviderChainで検証される全てのソースにおいてAWSのアクセスキーが指定されていることを確認してください。これらのソースの設定は、インスタンスプロファイルの認証情報を上書きします。 こちらが、インスタンスプロファイルの設定を間違って上書きしてしまった際に表示される可能性のあるエラーメッセージです。 com.amazonaws.services.s3.model.AmazonS3Exception: The AWS Access Key Id you provided does not exist in our records. (Service: Amazon S3; Status Code: 403; Error Code: InvalidAccessKeyId; 対応するRedshiftの操作が完了しているにもかかわらず、長時間のSparkクエリーがハングアップする Redshiftに対して大量のデータを読み書きする際に、Redshiftのモニタリングのページでは、Redshiftで対応するLOAD、UNLOADの処理は完了していると表示され、クラスターはアイドル状態になっていると表示されているにもかかわらず、Sparkのクエリーがハングアップする場合があります。これは、RedshiftとSpark間の接続がタイムアウトした場合に発生します。これを避けるには、JDBCフラグのtcpKeepAliveが有効化されており、TCPKeepAliveMinutesが小さい値(1など)になっていることを確認してください。 詳細はAmazon Redshift JDBC Driver Configurationを参照ください。 タイムスタンプとタイムゾーンのセマンティクス データを読み込む際、RedshiftのTIMESTAMPとTIMESTAMPTZデータタイプの両方は、SparkのTimestampTypeにマッピングされ、値は協定世界時(UTC)に変換され、UTCのタイムスタンプとして格納されます。RedshiftのTIMESTAMPにおいては、値はいかなるタイムゾーン情報を持たないものとして、ローカルのタイムゾーンが用いられます。Redshiftテーブルに書き込む際には、SparkのTimestampTypeはRedshiftのTIMESTAMPデータタイプにマッピングされます。 移行ガイド 現時点では、データソースがSparkのS3認証情報をRedshiftに転送する前に、明示的にforward_spark_s3_credentialsを指定する必要があります。aws_iam_roleやtemporary_aws_*認証機構を使用している場合には、この変更の影響はありません。しかし、過去のデフォルト動作に依存している場合、これまでのRedshiftからS3への認証機構を使い続けるのであれば、明示的にforward_spark_s3_credentialsをtrueに設定する必要があります。3つの認証機構とセキュリティ上のトレードオフに関する議論については、本記事のS3とRedshiftの認証を参照ください。 Databricks 無料トライアル Databricks 無料トライアル

Remote-Containerって便利 Lambda作るときにサクッとローカル環境つくりたかった。そしてローカル汚したくないのでDocker使おうと思いました。 1.ファイルコピー 予め作っておいた.devcontainerを作業ディレクトリを作ったらコピーする $ tree .devcontainer .devcontainer ├── Dockerfile └── devcontainer.json 内容は今のところシンプル。好きに育てればよいです。 Dockerfile FROM node:14 RUN set -x .devcontainer.json { "name": "Existing Dockerfile", "context": "..", "dockerFile": "./Dockerfile", "settings": { "terminal.integrated.shell.linux": null }, "extensions": [ "oderwat.indent-rainbow", "ionutvmi.path-autocomplete", "chrmarti.regex", "wayou.vscode-icons-mac", "alefragnani.bookmarks", "humao.rest-client" ] } vscode操作 [><]からReopen in Container 選んで実行 完成 あとは、npm init 使えるようになってるので、どんどん作っていけばいいです。 ローカルでバージョン管理とかやめれるのが良いのかなーと思っています。

AWSクラウドエンジニアのルビコン(@RubiconLink)です。 最近は本業のかたわら、駆け出しエンジニア向けにAWSのメンターに力を入れています。 結論 AWS管理画面は「English」一択だと思っています。 私に騙されたと思って今日から「English」を試してみてください。 「日本語」と「English」の見た目 AWSの管理画面を「日本語」で使われている方が多いと思います。 思い切って「English (US)」に変えてみましょう！ 頭がついていかない気持ち、心の抵抗は良く分かります。 私も英語が決して得意ではありません。 でも慣れてくると逆に「日本語」の方が気持ち悪くなってくる不思議！ なぜか？ 「English」のメリット 1. AWS CLI（awsコマンド）で使う名前と一緒 例えばAWS管理画面で「起動テンプレート」＝「Launch Template」ですが、AWS CLIでも英語ならもちろん同じ表記です。 最初から「起動テンプレート」と覚えるのと「Launch Template (ローンチテンプレート)」で覚えるのでは、全く別のサービスくらいの感覚差があります。 できれば最初からオリジナル・世界共通の名前で覚えてしまいましょう。 $ aws ec2 create-launch-template --launch-template-name <name> ... 2. CloudFormation（テンプレによるインフラ自動構築）でも同じく 当然ながらCloudFormationでも英語なら同じ表記です。 Type: AWS::EC2::LaunchTemplate Properties: LaunchTemplateName: <name> ... 3. （外国製あるある） 日本語が変。結局カタカナにしただけ。英語混在 もし日本語で表示させていると、例えば... 日本語の中に突然「Elastic IP」← 訳せなかった？？ 「Auto Scaling グループ」← グループだけカタカナ？？ CloudFrontの管理画面は全部英語 ← ネットに記事が少ないのはそのせいかも 日本語と英語の混在は読みづらくなります。 だったら最初から全部英語に！ 4. (冒頭の画像の通り) カタカナは折り返しが多くて、むしろ見づらい カタカナを使うとやたら名前が長くなるんですよね。 そうすると折り返しされてとても見づらいです。 やはり英語の方がスッキリしたデザインになっています。 5. いざ海外で働くとなっても「いつでもOK！」という自信 普段から英語でAWSを操作していれば、海外でもそのまま通用します。 海外に行かなくても海外の人と一緒に働く機会は増えています。 その場合でも抵抗なし！ また公式ドキュメントは英語しかない記事も多いです。 日本語があっても英語の方が正しかったり、新しかったりする場合も多々あります。 英語は結局避けられません。 割り切ってしまいましょう。 「English」のデメリット 1. マニュアルを書く時・スクショを撮る時・しゃべる時の違い 皆さん「日本語」なので、自分だけ「English」だと言葉が違うんですよね...。 正直、職場でも全員英語画面にさせたいくらいです。 改めて AWS管理画面は「English」一択だと思っています。 私に騙されたと思って今日から「English」を試してみてください。 最後までお読み頂き、ありがとうございました。 おまけ 週4稼働の現役クラウドエンジニアと並行して、毎日AWSの個別相談やグループ指導もお受けしています。もしご興味あればTwitter @RubiconLink のDMまでお問い合わせください。フォローも大歓迎です。

AWS Budgets 使ってますか？ AWSを個人利用したり、アカウント管理してる人だと使ってない人のほうが少ないですよね。きっと。 私その少数派でした。昔はバージニアリージョンにCloudWatchアラームをセットするのがお作法。満足して止まってたんです。 お金のしきい値見てアラートを出すだけならそれでも良いのですが、せっかくなのでどんな事ができるのか見てみることにします。 使ってみる なるほど。コスト予算のほかにいろいろ選べる。これが違う所なんですね。 現時点では、コスト総額の予算作成機能のみをご利用いただけます。AWS のコスト、使用量、予約情報がすべてバックフィルされ、AWS 予算機能の全セットが利用可能になるまでに最長で 4 日かかります。後でもう一度確認してください。 私の環境ではコスト予算しか選べないようでした。そのまま進んでみよう。 予算は５０USDで仮置きしてみる。次へ しきい値を求められた。割合でも出来るのか。とても優秀ですね。既に満足 SNSトピックに連携できるようでしたので連携し、その後メールか何かに繋げると良いと思います。 私はメール全く見ない人なのでLambdaからSlcakへ連携しています。 素敵なBudgetsライフを。 ※SNSのアクセスポリシーは以下を追記する必要がありました。 { "Sid": "AWSBudgets-notification-1", "Effect": "Allow", "Principal": { "Service": "budgets.amazonaws.com" }, "Action": "SNS:Publish", "Resource": "your topic ARN" },

はじめに DX 技術本部の yu-yama です。 AWS 認定ソリューションアーキテクト – プロフェッショナルを取得したので、取得までの流れと思考を記します。 受験前の AWS 経験 AWS 経験は 4, 5 年で、コアサービスはDev側/Ops側一通り触っており、SAA を 2020 年 6 月に取得、DVA を 2021 年 1 月に取得、SOA を 2021 年 2 月に取得しています。 AWS 認定ソリューションアーキテクトアソシエイト(SAA-C02)取得するまでにやったこと AWS 認定 デベロッパー – アソシエイト(DVA-C01)取得するまでにやったこと AWS 認定 SysOps アドミニストレーター – アソシエイト(SOA-C01)取得するまでにやったこと 学習期間 2 カ月 90H程度 学習の流れ 試験ガイドを確認 AWS-Certified-Solutions-Architect-Professional_Exam-Guide.pdf 分野ごとの比重を見て、特に問われるところを確認 分野 1: 組織の複雑さに対応する設計 12.5% 分野 2: 新しいソリューションの設計 31% 分野 3: 移行の計画 15% 分野 4: コスト管理 12.5% 分野 5: 既存のソリューションの継続的な改善 29% 試験の詳細を確認 形式：75 問 時間：180 分 Exam Readiness: AWS Certified Solutions Architect – Professional (Japanese) | AWS トレーニングと認定 受講 AWS の提供しているデジタルトレーニング(いつでも受けられるやつ)を見て問題の雰囲気をつかみます。ヒゲの優しそうなおじさんが問題を解く際のアプローチ方法を教えてくれてとても参考になります。 合格体験記確認 先人のやったことを確認し、どのような問題が出るか、どのような解き方をするか、どの問題集が良いか、どのような学習の仕方をするかを確認しします。 AWS 認定ソリューションアーキテクト – プロフェッショナル 合格記 | AWS WEB 問題集で学習しよう より koiwa だけでいけた。 問題文、選択肢ともに長く複雑 koiwa を 3 周 #30 以降は 4 周 #30 以降の答えが即答可能になっていれば OK #30 以降の問題を 2, 3 周 1 週間で 1 周のペースで(1 日#8 つ) 6 周の人も 問題の解説は徹底的に読んで理解する koiwa で 90%取得が一つの目安 5 割程度 koiwa と類似した問題が出題 問題で問われている要件からソリューションを(コスト、可用性、パフォーマンスなど)パターン分けしながら考えるとよい 学習期間は 1-3 カ月程度 類似はサクっと解いて、初見の問題に時間をかける時間配分が大切 アソシエイトとは異次元で比べ物にならないくらい難しい 本試験モードで 8 割超えたら受験しても良いかも 本試験モードを何度か実施して慣れておいた方が良い パッと見でややこしかったらフラグ立てて次に飛ばして見直しで戻って解く Udemy はあまり似た問題が出ず、koiwa が良い Udemy は試験より難しい印象 Udemy は試験より難易度が高い Udemy オプションの設定やコマンドの問題が用意されているが、本試験では出ない 「AWS 認定ソリューションアーキテクト - プロフェッショナル」に一発で合格する技術(2020/11 版) より 問題に出たテーマやキーワードの理解に専念して、ある程度理解できたらそれ以上深入りをしない 【AWS SAP 認定試験】約 1 ヶ月で一発合格！合格のコツとは！？ ～中編～ - ailes blog より 問題を解き、解けなかった問題に対してはなぜその答えなのか、なぜ他の答えではダメなのかを理解し、その問題を解けるようになるまで頭に叩き込みます。 模擬試験モードを 2 回実施しました。 1 回目が 78%、2 回目が 77%だったため、2 回目で正解率が上がりませんでした。 ですが、最低ラインの 75%は超えていたため、そこまで不安になることはありませんでした。（あくまで楽観的な観測ですが、スピード優先なので） あとは通常問題の 2 週目が十分に走りにきってなかった、2 回目の問題をきちんと復習して理解しきれた、という点もありました。 AWS 認定ソリューションアーキテクト – プロフェッショナルの新試験に合格した話 | MISO より 本番と似たような雰囲気の問題を数多く解き、素早く回答する練習をする この試験は集中力と気力と体力の勝負 AWS 認定試験のプロフェッショナルレベルに合格したので何やったかをまとめる より 3 時間集中して問題解くのしんどい。 個人差はあると思うけど、自分は SAP と DOP の両試験とも全問解いて 10 数分くらいの残り時間しか無かった。 なので、後で見直す時間はほぼ無いと思って良さそう。 「後で見直す」フラグを問題に付けることができて後で見返せるんだけど、本気で回答に迷った問題だけに留めておこうと反省。分からない問題は”分からん”と認めて後戻りしないこと。 【2019 年改定後】AWS 認定ソリューションアーキテクト プロフェッショナル(SAP)合格のために勉強したこと より 問題集を解きまくる 弱いと感じた部分を BlackBelt 中心に勉強する（ノートに取る） 再度問題集を解きまくる 模試を受ける 模試の内容を完璧に理解する 本番に臨む AWS 認定ソリューションアーキテクト – プロフェッショナルの合格記 ～ 3 時間の苦闘～ - IT 資格取得～受験料の節約～ より 本番では問題集と同じような問題はあまり出題されず、かつ、試験範囲も網羅していない』とのことだったので、単純に繰り返すのではなく、 正解ではない選択肢、解説に出てくるサービスや機能も、概要レベルが理解できるまでひたすらググる ソリューションアーキテクト – プロフェッショナル資格試験合格体験記と学習のコツ【AWS 認定試験】 - IT の現場から DX/デジタル経営の実現に向けたマイグレーションとクラウド活用 より - （主にコンピューティングまわりの）AWS アカウント内、リージョン間、AZ 間でできることの整理 　これは本当に学習していてよかったと思います。 　 EC2 や ELB、AMI などをリージョン間やアカウントをまたいで移動する場合や、 　 RDS でフェイルオーバーする場合など、サービスの標準的な機能で対応できるのか、 　他のサービスと組み合わせる必要があるのか、しっかり整理しておく必要があります。 基本的に他の選択肢も、全く違和感のないものばかりなので、 　知らないと正解を絞り込むのが難しくなります。 - 必ず解答を 2 回以上見直す アソシエイトレベルに比べると、試験時間に余裕はないと思いますが、 必ず見直しもかねて 2 周した方が良いです。 これは実際の私の経験ですが、最初の方で自信をもって回答できなかった問題が、 後半で別の観点で問われていて、最初の問題を正解の選択肢に絞り込めたことが何問かありました。 2 択まで絞り込んだけれど、どちらか確信を持てないケースは AWS 認定試験でよくあるので、 2 周する事で正解を拾えればかなり合格に近づけます。 - 残り時間を小まめに確認する 私が受験した PSI の試験では、残りの回答時間と問題数が表示されていたので、 残り時間を残り問題数で割って、1 問あたりににかけられる時間を小まめに確認していました。 残り 30 問で残時間 60 分だったら、1 問 2 分までかけられますが、 最後に見直しする想定だと、実質 1 分程度しかかけられないことになります。 難問に集中していると時間を忘れてしまいがちですが、 残りの時間を有効活用するために常に把握しておくのがおススメです。 【試験合格記】AWS 認定ソリューションアーキテクト – プロフェッショナル(SAP-C01) - Qiita より - 再学習して久しぶりに気付いたのですが、やはり AWS 試験の最難関は間違いなくこの SAP だと思います。 学習範囲と予測の難しさは脳死で学習支援サイトの問題を解いても身につかないのは間違いないでしょう。 地道に日々 AWS と戯れて各サービスのベストプラクティスを理解するように心がけていく必要があると再認識しました。 - ハイブリッドクラウド、AWS への移行、Organization レベルの適切な管理 - AWS Organization のマスターアカウントと配下アカウントの関係性を理解する - SCP やアクセス権限の境界で出来ることを把握する - 災害復旧(DR)を計画するにあたって起点となるリソースや設定の違いを理解する - RDS や DynamoDB の特性を正しく理解する - DirectConnect、VPN、VPC Peering、Transit Gateway などネットワークリソースの特徴およびユースケースを学ぶ - セキュリティの最適化に NACL、Security Group、WAF などをどのレイヤーに設置すべきか判断できるようにする - EC2、Elastic Beanstalk、Lambda、ECS などコンピュートリソースの特徴と応用的な使い方を理解する アソシエイトと異なりしんどいとか脳死とか思い出すだけで吐きそうとか恐ろしい単語が並んでいます... 問題は長文で、長文の似たような内容で迷う回答が出ること。幅広いサービスの知識が必要になるので個々のサービスを深堀して学習するのは非効率であること。 時間が足りなくなるので 1 問 2 分ペースでサクサク解くこと。(ここは時間が確実に余るアソシエイトとは違いますね)などが分かりました。 見た感じ AWS WEB 問題集で学習しよう が概ね評判が良い感じでしたので、これをやってみることにしました。 Udemy の問題集 は評価が分かれていましたが、問題が本試験より難易度が高いこと、出ない(と個人的には思っている)問題(パラメーターやオプション、制限の値)が以前アソシエイトの問題集をやった際に結構混ざっていたためパスしました。75 問全て解かないと回答と解説が確認できない点もマイナスでした。 SAP | AWS WEB 問題集で学習しよう(koiwa) を解く 問題集が7問1セットのトータル55セット(385問)用意されています。1周回ってから1度受験することに。 koiwa は1問解くごとに回答と解説が表示されるため、細切れに学習を進めるのに適しています。 問題を解く → 回答を一通り読む(正解でも) → 理解できない箇所や弱いと感じる箇所はブラックベルトを確認する。(ただしあまり深堀しすぎないように) と進めました。 1 周回ったのですが最後まで今一つな正解率でした(アベレージ 5,6 割？)。まあ一度受けてみるかということで受験しました。 模擬試験 受けてません。 本番 試験時間は 180 分なので 1問2分ペースとして、残120分残45問、残60分で残15問とペース配分決めて開始しました。 問題は噂通り長文長文...koiwa と類似した問題が出ると合格記にありましたが全然そんなことはなかったです。 若干ペース遅れつつも残 30 分で全問回答しました。 その後解き漏れが無いか確認したところ、2 問もありました。複数回答を選択しなくてはいけないところを 1 つのみで進めていたようです。長文で疲弊していたのか。 その後見直しフラグを立てたものの確認へ。再度読み直すも...全く内容が頭に入ってきません。 まあいいか。と思い直して試験を終了すると、合格していました。 感想 と まとめ サービスの知識はやはり全般的に問われます。これらをやっておけば OK というのは無いです。 SAP | AWS WEB 問題集で学習しよう について 合格記に#30以降を即答や90%取得が目安とありますがそんなことはないです。 全体的に問題が少し古いです Lambda の実行時間制限 5 分になっていたり Transit VPC が回答になっているところは今は Transit Gateway だろ的なところがあったり やたら回答に出てきていたけど SWF っていま使う？など とはいえ長文の問題と選択肢の雰囲気に慣れるという意味と、各分野ごとのベストプラクティスを把握するという意味ではではかなり有用でした。問題集を 1 から解き始めず、後ろの方から 30 セット(210 問)解いて受けるでも良かったかも。 最後に回答漏れが無いかちゃんと確認しよう 見直しフラグの時には集中力がゼロになっているかもを念頭に。 問題の読み方 問題はちゃんと最後までじっくり読みます。構成図を頭に描きつつ読みます。 最後のあたりに出てくるキーワードに注目します。 - コンプライアンス - 低コスト, 費用対効果 - セキュリティ - 最小限の管理工数 - RPO, RTO - 可用性 - アプリケーションに殆ど変更を加えず - アプリケーションのダウンタイムを最小限に押さえる - 移行に許容される時間 - パフォーマンス 回答の選び方 回答も全て読んでいると時間が無くなるので回答は少し引いて(俯瞰して)読みます。 問題文で脳内に描いた構成図とキーワードから大体 2 つ程度に絞れます。 その後、回答もじっくり読みます。 それで正解が分かればそれで。 どちらも判断が付かない場合、最初に文章を読んだ時にひっかかりが少なかった方を選択しましょう。 このサービスとこのサービスの組み合わせに違和感を感じる...などなにかしら感じるものです 合格記でよく見かけましたが本当に体力・集中力勝負なので前日はたっぷり睡眠を取りましょう。 最後に問題集解いている時に作成したメモを貼っておきます 試験に向けて作成していたメモ ヒューリスティック 「経験則」の「試行錯誤的な」の意味 Amazon EMR(Elastic MapReduce) ビッグデータ処理のクラウドプラットフォーム Apache Spark, Apache Hive などのオープンソースを使用して膨大な量のデータを処理できる ノード マスターノード クラスターを管理する 稼働し続けなければならない コアノード 計算タスクを実行する コストを抑えるベストプラクティス マスターノードとコアノードにオンデマンドまたはリザーブドインスタンスを使用し、タスクノードにはスポットインスタンスを使用する EMR は 1 秒あたりの課金になるので、スポットインスタンスを利用してコストを削減して、スポットインスタンスの数を増やすことによってパフォーマンスを高く出来る Amazon Kinesis リアルタイムのデータキャプチャと分析のために Amazon kinesis を使用する ストリーミングデータを処理できる クリックストリームなど 高速にデータを使用してアドホック分析(必要に応じて必要なだけ行う分析)を実行するには Kinesis Firehose ＋ Redshift を使用する Redshift はアドホッククエリもサポートしている Kinesis Data Firehose は、Elasticsearch Service へデータを直接送信できる Kinesis と SQS の使い分け リアルタイム性を求めるなら Kinesis 処理の欠落を回避したいなら SQS Kinesis Video Streams 接続されたデバイスから AWS へ動画を簡単かつ安全にストリーミングの保存、暗号化、インデックス化を行う 保存された映像は API を使用してストリーミング配信できる Amazon SQS 既存のキューは作成後に変更できない デフォルトのスタンダードキューはメッセージの順序を保証しない。メッセージの順序を保証するには SQS FIFO キューに移行する必要がある SQS FIFO キーは単一のキュー内で複数の順序付けされたメッセージグループを許可する SQS を使用するとタスクをキューに送信して非同期的に処理できる SQS メッセージキューはリージョンごとに独立している SNS モバイルプッシュデバイスのアプリケーションにプッシュ通知メッセージを直接送信できる SNS と SQS SNS は負荷分散に適したサービスではない SQS は並行して動作する CloudFront コンテンツを CloudFront から配信することで、サーバーへのアクセス負荷を減らす オリジンサーバ(コンテンツオリジン) 配信元となるサーバのこと EC2 や S3 の他にオンプレミスサーバーも指定できる オリジンアクセスアイデンティティ(OAI) ユーザーが S3 バケットへ直接でなく、CloudFront 経由でのみファイルにアクセスできるようになる CloudFront でオリジンアクセスアイデンティティを作成する S3 のバケットポリシーとして、そのオリジンアクセスアイデンティティからのリクエストのみ受け付ける設定にする CloudFront で SSL/TLS の証明書を使用するための要件 ビューワーと CloudFront との間の HTTPS 通信に自己署名証明書を使用することはできない CloudFront とオリジンとの間の HTTPS 通信に自己署名証明書を使用することはできない ビューアで CloudFront デフォルト証明書、オリジンでサードパーティの CA 証明書 もしくはビューアで CloudFront、オリジンでサードパーティの CA 証明書 CloudFront のキャッシュ動作 ウェブサイトにあるファイルの特定の URL パスパターンに応じてさまざまな CloudFront 機能を設定できる 動画ストリーミングに Amazon CloudFront を使用する CloudFront ではプログレッシブオプションに設定されたダウンロードオプションを利用して、動画のストリーミングをサポートできる CloudFront 署名付き Cookie 複数の制限付きファイルへのアクセスを提供する場合、誰がコンテンツにアクセスできるかを制御することが出来る 選ばれたユーザー (料金を支払っているユーザーなど) のドキュメント、ビジネスデータ、メディアストリーム、またはコンテンツに対して、アクセスを制限する CloudFront に ACM で取得した証明書を適用する場合、 us-east-1(バージニア北部) の ACM で証明書を取得しなければいけない CloudFront はグローバルリージョンのため ACM の証明書はリージョンごとに要求する必要がある 高可用性を満たすために CloudFront オリジンフェールオーバーを使用する オリジングループを作成し、CloudFront のプライマリオリジンが特定の HTTP ステータスコードの失敗応答を返した時に CloudFront が自動的に切り替わる 2 番目のオリジンを指定する これにより、HTTP504 エラーが軽減される AWS Lambda＠Edge CloudFront の機能 AWS Lambda の拡張機能で、CloudFront が配信するコンテンツをカスタマイズする関数を実行できる キャッシュ機能はない AWS Connector for vCenter 仮想マシンを Amazon EC2 に移行する AWS Systems Manager(SSM) パッチ適用のプロセスの自動化に役立つ セキュリティ関連のアップデートと他のタイプのアップデートの両方でマネージドインスタンスにパッチを適用するプロセスを自動化する オンプレミスで使用されているパッチベースラインと VPC 内の全ての EC2 インスタンスと同期させてタスクとパッチ適用スケジュールを自動化するタスクを導入する方法 AWS Systems Manager Patch Manager を使用して、オンプレミスのデータセンターのパッチベースラインに基づいて EC2 インスタンスのセキュリティパッチを管理及びデプロイする SSM エージェントをすべてのインスタンス、オンプレサーバにインストールする AWS Systems Manager メンテナンスウィンドウを使用してパッチ適用スケジュールを自動化する パッチ計画例 本番環境以外でパッチをテストし、適切な承認を得てメンテナンス期間中に展開する すべてのサーバワークロードでパッチあてによる EC2 インスタンスの再起動が同時に発生しないことが重要 例) Windows Server1, Windows Server2 いずれかの値をもつパッチグループのタグを追加 重複しない 2 つの AWS Systems Manager メンテナンスウィンドウを定義し、異なるパッチグループに関連付ける AWS DefaultPatchBaseline を使用してパッチを決定 メンテナンスウィンドウを作成し、AWS-RunPatchBaseline ドキュメントを使用してパッチを適用する インスタンスにパッチを適用する SSM ドキュメント SSM ドキュメントには、パッチ適用オプションの詳細が記載されている AWS CloudSearch マネージド型サービスであり、ウェブサイトまたはアプリケーション向けの検索ソリューションを容易かつコスト効率よく設定、管理、スケールできる エンドツーエンド暗号化（end-to-end encryption, E2EE） 通信ネットワークにおいて通信を行う送信者と受信者のみが暗号化されたデータを復号、閲覧できる仕組みの秘匿性の高い暗号化技術のこと。 S3 構造化データのストレージソリューション 署名付き URL ある特定の URL からのみアクセスできるようにするための機能 アプリケーションが URL を生成する必要があり、URL を生成するために適切な資格情報が必要 リクエスタ支払いバケット バケット所有者ではなくリクエストを実行するリクエスタが支払う データを共有したいが、費用を負担したくない場合に使用する 手順 データを所有するバケットにバケットポリシーを作成する 作成したポリシーに参照させたいアカウントの読み取りアクセス許可を設定 バケットでリクエスタ支払いを有効にする リクエスタがデータにアクセスするときにヘッダにリクエストが課金されていることを認識しているヘッダ x-amz-request-payer を含める S3 はデータを保護するための最もコスト効果の高い選択。また、S3 Range Get を使用すると、オブジェクト全体を読み込むのではなく、必要な部分またはバイトのみを読み取ることが出来る マルチパートアップロード 費用を最適化するため、クライアントから直接 S3 にアップロードさせる オブジェクトサイズが 100MB 以上の場合、単一のオペレーションでオブジェクトをアップロードする代わりにマルチパートアップロードを検討すること S3 Glacier はストレージとプットに時間がかかるため、個々のファイルを保存するのは費用対効果が薄い 1 つのアーカイブとしてアップロードして、ファイルの一部を S3 Glacier でバイト範囲で取得出来る S3 クロスリージョンレプリケーション S3 のデータを DR リージョンにコピーするのに役立つ S3 Transfer Acceleraition クライアント Amazon S3 バケットの長距離間でファイルを高速、簡単、安全に転送できる S3 のアップロードパフォーマンスの向上に役立つ オブジェクトの格納と格納されたオブジェクトへの迅速なアクセスに関する設計パターン S3 と DynamoDB を用いる DynamoDB グローバルテーブルおよび S3 クロスリージョンレプリケーションはリージョン障害からデータを保護する 静的ページの配信は S3 ストレージと CloudFront が定石 Amazon Elastic Transcoder 動画ファイルをパソコンやスマートフォン、タブレットなどで再生可能なフォーマットに変換するサービス トランスエンコードで Elastic Transcoder を用いて、元ファイルは S3 Glacier にアーカイブして、S3 から CloudFront で配信することで、コスト効率が高いアーキテクチャを構築できる インスタンスのプロファイルプロパティ インスタンスプロファイルを作成して、IAM ロールを EC2 インスタンスに渡す IAM ロールを収めるための容器 マネコン以外、AWS CLI や CloudFormation で意識する必要がある AWS Service Catalog AWS のプロビジョニングに関するリスクを低減する(コスト、セキュリティ、ガバナンス) 標準的な AWS 環境のデプロイをテンプレート化する テンプレートのバージョン管理を行う 製品 CloudFormation テンプレートをパッケージ化したもの バージョンが管理可能 ポートフォリオ 製品の集合 ポートフォリオ単位でユーザーに製品の使用を許可 制約 製品のデプロイ方法を制御。ポートフォリオごとに各製品に制約を追加 AWS Organizations はサービスカタログと統合でき、インフラストラクチャを一元管理してポリシーを適用するために使用できる 所属組織でメンバーアカウントとの Service Catalog のポートフォリオ共有を簡素化できる RDS for MySQL オンプレミスへのレプリケーション セキュリティのために VPN 接続を使用して AWS からオンプレミスのデータベースインスタンスへレプリケーションできる 不正侵入検知・防御システム(IDS・IPS) インスタンスまたはリバースプロキシ層に IDS/IPS エージェントを実装することでインターネットからのトラフィックを保護できる IdP(Identity Provider) クラウドサービスやアプリへのアクセスを試みるユーザーの ID やパスワードなどの認証情報を提供する ウェブアイデンティティフェデレーション ウェブ ID フェデレーションは Amazon, Facebook, Google またはその他の OpenID Connect 互換の IdP でのログインができる ウェブアイデンティティフェデレーションを使用して取得した一時的な AWS 資格情報は、モバイルアプリケーションで必要なタスクを実行するために必要な権限のみを持つ AWS ロールにマップされる ユーザーに一般的なサードパーティー ID プロバイダーを使用したサインインを求める そのプロバイダーの認証情報を AWS アカウントのリソースを使用するための一時的なアクセス許可に変換する AWS リソース(DynamoDB etc)にアクセスする SAML2.0 フェデレーティッドユーザーが AWS マネジメントコンソールにアクセス可能にする AWS マネジメントコンソールに再度サインインしないようにするため、オンプレミスの SSO を使用してネットワークオペレーションセンターのメンバーに AWS マネジメントコンソールへのアクセスを許可する SAML Security Assertion Markup Language の略称であり、OASIS によって策定された異なるインターネットドメイン間でユーザー認証を行うための XML をベースにした標準規格 SAML IdP(Identity Provider) 認証情報を提供する側のこと フェデレーション 一度認証を通れば、その認証情報を使って、許可されているすべてのサービスを使えるようにする仕組みのこと ユーザーは組織のポータル(IdP)にアクセス ポータル(IdP)が認証(ADFS etc)を行う ポータル(IdP)は、ユーザー識別するアサーションを含む SAML アサーションレスポンスを生成し、クライアントブラウザに返す クライアントブラウザは、AWS のシングルサインオンエンドポイントにリダイレクトされ、SAML アサーションを投稿する AWS STS AssumeRoleWithSAML API を呼び出す SAML プロバイダーの ARN 引き受ける IAM ロールの ARN ポータル(IdP)からの SAML アサーション エンドポイントは、ユーザーの代わりに一時的なセキュリティ認証情報をリクエストし、コンソールのサインイン URL を作成します AWS は、サインイン URL をクライアントにリダイレクトとして送信 クライアントのブラウザは、AWS マネジメントコンソールにリダイレクトされる ID プロバイダー(IdP)とフェデレーション 適切なアクセス許可で IAM ロールを作成し、フェデレーションまたは ID プロバイダーを使用してオンプレミスの会社の AD または LDAP で認証し、STS を呼び出して一時トークンを生成して、S3 へのアクセスを制限する AWS STS(Security Token Service) ユーザーに対して IAM を定義せずに AWS リソースへのアクセスを許可できる ID プロバイダー(IdP)とフェデレーション LDAP などで認証し、AssumeRole を呼び出す方法と カスタム ID ブローカーの実装を使用し、LDAP などで認証し、フェデレーショントークンを使用する方法 AD コネクター ディレクトリリクエストをオンプレミスの Active Directory へリダイレクトするのに使用するディレクトリゲートウェイ AWS Storage Gateway ファイルゲートウェイ NFS や SMB などのプロトコルを利用して S3 オブジェクトを保存及び取得できる S3 を永続ストレージとしてオフサイトのバックアップを提供する オフサイト 現地から離れた。遠隔地の。 ボリュームゲートウェイ オンプレミスのアプリケーションサーバから iSCSI デバイスとしてマウントできる、クラウドベースのストレージボリュームを提供 キャッシュボリューム 頻繁にアクセスするデータサブセットのコピーをローカルに保持 データを S3 に保存し、頻繁にアクセスするデータサブセットのコピーをローカルに保存する 保管型ボリューム データセット全体への低レイテンシーアクセスが必要な設定は、最初に全てのデータをローカルに保存するようにオンプレミスのゲートウェイを設定する テープゲートウェイ バックアップデータをコスト効果や耐久性の高い方法で S3 Glacier などにアーカイブできる オンプレミスからの移行 VPC とオンプレミスと重複しない IP アドレス空間にして、AWS Direct Connect で VPC とオンプレミスの内部ネットワークのリンクを確立させる 現在の仮想マシンを VM Import で AWS に移行する DR 戦略 バックアップ＆リストア データとリソースがバックアップされる パイロットライト 費用対効果の高い戦略を備えるディザスタリカバリ 別のリージョンにリードレプリカを作成し、アプリケーション基盤の AWS CloudFormation を作成。障害が発生したら、リードレプリカを昇格させて Amazon RDS MySQL マルチ AZ 配置を使用した DB インスタンスとして設定。昇格させた Amazon RDS DB インスタンスを使用して別のリージョンの環境を AWS CloudFormation テンプレートを使用して作成する。DNS レコードを更新して、他のリージョンを指すようにする EBS と RDS をパイロットライトで使用する例 AWS Lambda を使用して、毎日 EBS および RDS のスナップショットを作成 それらを災害復旧リージョンにコピーする Route53 ヘルスチェックを使用してフェイルオーバー(アクティブ／パッシブ)を設定する 災害復旧リージョンで容量を 0 に設定した Auto Scaling グループで EC2 を使用する ウォームスタンバイ 完全に機能的な環境の縮小版が常に実行されている マルチサイト アクティブアクティブ構成 上に行くほど可用性が低くコストが低い 下に行くほど可用性が高くコストが高い マルチ AZ を使用することにより、地理的冗長性の安全性と信頼性を利用できる クロスリージョンリードレプリカ RDS を使用すると、リードレプリカをソース DB インスタンスとは異なる AWS リージョンに作成できる VPC エンドポイント 冗長性と高可用性を備え、水平にスケールする ネットワークトラフィックに対する可用性のリスクや帯域幅の制約はない S3 および DynamoDB 用の VPC エンドポイントを利用するために、ゲートウェイエンドポイントを作成する必要がある Amazon DLM(Data Lifecycle Manager) Amazon EBS ボリュームをバックアップする為の Snapshot の生成 → 保存 → 削除のライフサイクルを自動化するサービス NAT ゲートウェイ NAT ゲートウェイはネットワークアドレス変換を提供する Elastic IP アドレスを NAT に割り当てると、単一の IP をホワイトリストに登録できる支払いゲートウェイに公開できる IPv4 のみ Egress-Only インターネットゲートウェイ プライベートサブネット内のインスタンスからインターネットへ IPv6 トラフィックをルーティングするために使用する VPC 内に Egress-Only インターネットゲートウェイを作成する 全ての IPv6 トラフィック(::/0)または特定の IPv6 のアドレスの範囲をポイントするルートテーブルに、Egress-Only インターネットゲートウェイへのルートを追加する ステートフルである NAT ゲートウェイは IPv6 をサポートしない インスタンスストア(エフェメラルドライブ) 各 EC2 インスタンスと同じ物理ホストに存在しているディスクのことで、無料で利用できるディスクのこと。 このディスクは EBS に比べ高速にアクセスすることができますが、揮発性のディスクのため、サーバを停止するとディスク上のデータが消える。 ユーザーデータ EC2 でインスタンスを起動するとき、起動後にそのインスタンスにデータを渡し、一般的な自動設定タスクを実行したり、スクリプトを実行したりできる VPC ピア接続 2 つの VPC 間の 1:1 関係 50 のアカウントの各 VPC 間でプライベート DNS を利用するには 共有 VPC を作成 他のアカウントの各 VPC への VPC ピアリング接続を作成する ドメインおよびサブドメインのリソースレコードセットを作成する Amazon Route 53 プライベートホストゾーンを共有 VPC に関連付ける VPC ピアリング間のデータ接続料金は、インターネットまたはリージョン間のデータ転送料金と比較して安い セキュリティグループは VPC ピアリングしている際に VPC をまたいでセキュリティグループの送信元にセキュリティグループを設定できるが、リージョンをまたいだ設定はできない VPC ピアリング接続はエッジツーエッジのルーティングをサポートしない エッジツーエッジルーティングとは VPC をまたぐネットワークトラフィックは送信できない VPC ピアリングは サブネットに設定したルーティングテーブルで VPC 間の接続を制御する VPC ピアリング 自分の AWS アカウントの VPC 間や、他の AWS アカウントの VPC との間に作成出来る VPC は複数の異なるリージョン間に存在できる VPC のルートテーブルは、プレフィックス最長一致を使用して、最も具体的なルートを選択する CloudTrail ログファイルを複数のリージョンから受け取る 1 つのアカウントの 1 つの S3 のバケットに配信するように設定できる 監査に使用できる CloudTrail ログは通常 15 分遅れて表示されるようになる AWS PrivateLink Amazon のネットワーク内で、VPC、AWS のサービス、オンプレミスアプリケーション間のセキュアなプライベート接続を提供する BGP を介したオンプレミスネットワークのスタティックルートの伝播 Border Gateway Protocol 現在のインターネットにおいて、ISP などの相互接続時にお互いの経路情報をやり取りするために使われる経路制御プロトコル Amazon SWF(Simple Workflow) 並行したステップまたは連続したステップがあるバックグラウンドジョブを構築、実行、スケールする ディサイダー ワークフロー実行中に実行されるワークフロータイプの調整ロジックの実装のこと Classic Load Balancer は 1 つの証明書しか登録することが出来ない ALB は複数証明書設定 OK ELB はクライアント証明書を利用した認証をサポートしない クライアント証明書とサーバ証明書の違い クライアントを証明する クライアントのブラウザなどにインストールして利用する 1 人に一人配布される サーバを証明する KMS と CloudHSM 鍵が AWS 環境外に移動しなくなるため安全 KMS：マルチテナント方式のマネージド暗号鍵管理サービス お手軽 キーポリシーを使用して権限を制御する CloudHSM：シングルテナント方式の暗号鍵サービス KMS 経由で、AWS サービスと連携 KMS の鍵管理に加え、暗号化、復号処理のアクセラレーション 高いレベルのコンプライアンスへの対応 Proxy Protocol ヘッダー ロードバランサーでバックエンド接続用に TCP を使用する場合に、クライアントの IP アドレスを識別するのに役立つ VPC で、インスタンスがカスタマーゲートウェイに到達できるようにするには、 VPN 接続で使用されるルートを含め、仮想プライベートゲートウェイを指すようにルートテーブルを設定する必要がある 仮想プライベートゲートウェイへのルート伝播を有効にする必要がある ENI を EC2 インスタンスに増やしても、ネットワーク帯域幅の増加には役立たない Route 53 Route53 ルーティングポリシー 位置情報ルーティングポリシー ユーザーの IP アドレスから接続場所を特定し、地理的に近い場所のレコードを返す ユースケース例) ドイツ在住の人にはドイツ語のコンテンツを表示したい場合など 地理的近接性ルーティングポリシー リソースの場所に基づいてトラフィックをルーティング ユースケース例) アジア地域のユーザーが地理的に近くの CloudFront リソースにルーティング シンプルルーティングポリシー ドメインで特定の機能を実行する単一のリソースがある場合に使用します。たとえば、example.com ウェブサイトにコンテンツを提供する 1 つのウェブサーバーなどです。 フェイルオーバールーティングポリシー アクティブ/パッシブフェイルオーバーを構成する場合に使用します。 レイテンシールーティングポリシー 複数の AWS リージョンにリソースがあり、レイテンシーの最も小さいリージョンにトラフィックをルーティングする場合に使用します。 複数値回答ルーティングポリシー ランダムに選ばれた最大 8 つの正常なレコードを使用して Route 53 が DNS クエリに応答する場合に使用します。 加重ルーティングポリシー 指定した比率で複数のリソースにトラフィックをルーティングする場合に使用します。 Amazon Route 53 加重ラウンドロビン パーセンテージでトラフィックを分散する Route 53 がエンドポイントをモニタリングするヘルスチェックのステータスを決定する方法 ウェブサービスの場合、HTTP/HTTPS ヘルスチェックエンドポイントが必要であり、HTTP ステータスコード 2xx または 3xx でエンドポイントが応答する必要がある。 また、文字列の一致はレスポンス本文の最初の 5,120 バイト内に出現している必要がある Route53 プライベートホストゾーンを別の AWS アカウントの VPC に関連付ける アカウント A の EC2 インスタンスに接続する アカウント A のプライベートホストゾーンとアカウント B の VPC 間の関連付けの承認を作成する アカウント B の EC2 インスタンスに接続する アカウント A のプライベートホストゾーンとアカウント B の VPC 間の関連付けを作成する アカウント A の EC2 インスタンスに接続する アカウント A のプライベートホストゾーンとアカウント B の VPC 間の関連付けの承認を削除する これでアカウント B の EC2 インスタンスはアカウント A のプライベートホストゾーンのレコードを解決できるようになる バックアップ VPN 接続を使用した AWS Direct Connect コストを抑えながら AWS とオンプレの接続の冗長化を確保する デフォルトでは AWS は常に Direct Connect 接続を開始してトラフィックを送信することを選択するため、プライマリ接続とバックアップ接続を定義するための追加の構成は不要 AWS Direct Connect 仮想インタフェース AWS のサービス(パブリックリソース)にアクセスするには、パブリック仮想インタフェースを作成し、BGP セッションを確立する必要がある。 AWS のパブリックエンドポイントに専用ネットワークパフォーマンスを利用して DirectConnect 接続できる また、パブリック仮想インターフェイスを作成して、BGP セッションを確立すると、ルータがルートを学習してデータを転送できる。 インターネットを経由せずに、インターフェイス経由でパブリックネットワークにアクセス出来る プライベート仮想インターフェイス プライベート IP アドレスを利用して Amazon VPC にアクセスできる BGP(Border Gateway Protocol) セッション ISP などの相互接続時にお互いの経路情報をやり取りするために使われる経路制御プロトコル BGP セッションを確立すると、ルーターがルートを学習してデータを転送できる スタティックルーティング(静的ルート) 経路情報の更新を人間の手で行う Direct Connect ゲートウェイ Direct Connect ゲートウェイをいずれかの AWS リージョンに作成すると、AWS の全リージョンに複製され、相互接続できる パブリック IP アドレスへのアクセス制限は、パブリック IP アドレスが変更される可能性があり、リスクが増大する IAM ポリシー "Condition" : { "条件演算子1": { "キー1": ["値1","値2"] "キー2": "値3" }, "条件演算子2": { "キー3": "値4" } } 条件演算子 1 と 2 は AND キー 1 内の値 1 と値 2 は OR キー 1 とキー 2 は AND 認証情報はハードコーディングしないこと グローバルサービスイベント IAM, Route53, CloudFront, WAF etc DynamodB DynamoDB のスループット削減 SQS を使用してアーキテクチャを分離し、DynamoDB のスループットを削減してパフォーマンスを維持し、コストを低く抑えることが出来る 読み取りキャッシュに SQS は使用しないこと。ユーザーの応答を非同期にしてしまい、エクスペリエンスとパフォーマンスに影響を与える DynamoDB のパフォーマンス DAX(DynamoDB Accelerator) は読み取りパフォーマンスを改善します。 DynamoDB にインメモリキャッシュ型の機能を付加する DynamoDB クロスリージョンレプリケーション 必要な RPO と RTO と Lastupdated 時間を持つ DR のために役立ち、更新された項目だけをレプリケートするのに役立つ クロスリージョンレプリケーションを使用すると、ある AWS リージョンから別のリージョンの DynamoDB テーブルへの DynamoDB テーブルデータの定期的なコピーを構成できる DynamoDB は自動スケーリングされたインスタンスを介した取り込みスループットをサポートできる RDS では高い読み込みスループットに対応出来ない データベースの書き込みを一切落とさないために、Amazon SQS を使用して、メッセージの少なくとも 1 回の配信で耐久性を提供し、DynamoDB への書き込みをバッファリングできる DynamoDB はユーザのプリファレンスを保存するのに最適。 プリファレンス あるソフトウェアの挙動や表示の仕方などを利用者が好みや必要に応じて変更するための設定情報や設定画面、設定ファイルなどのこと DynamoDB ストリームはデータに加えられた変更に対してリアルタイムにストリームを提供できる Lambda 関数にてデータを Kinesis Data Streams に共有して異常を検出し、SNS 通知を使用して送信することが出来る Kinesis Data Streams および Lambda を使用すると、コスト効率の高い取り込みソリューションが可能。また、DynamoDB は、データベース層のスケーリングに役立ち、必要な書き込みパフォーマンスを提供する DynamoDB の TTL ユースケース アプリケーションで 1 年間非アクティブ状態が続いた後、ユーザーまたはセンサーのデーターを削除する Streams および AWS Lambda を使用して、期限切れの項目を Amazon D3 データレイクにアーカイブする 契約上の義務または規制上の義務に従って、機密データを一定期間保持します IAM の権限は委譲できない 明示的な拒否のみ Amazon Data Pipeline データの移動や変換を簡単に自動化する CUDA(Compute Unified Device Architecture)(クーダ) NVIDIA が開発・提供している GPU 向けの汎用並列コンピューティングプラットフォーム DHCP オプションセット VPC 内に関連付ける DHCP 関連の設定のこと ドメイン名、ドメインネームサーバー、NTP サーバ、NetBIOS ネームサーバーなどが設定できる 変更する場合、既存のものは変更ができないため、新しい DHCP オプションセットを作成し、それを VPC に関連付ける プロビジョンド IOPS SSD(io1) ボリューム ボリュームサイズに対するプロビジョンド IOPS の最大割合は(50GB 単位)50:1 例) 100GB のボリュームだと最大 5,000 IOPS でプロビジョニングできる ENI(Elastic Network Interface) プライベート IP アドレス、固定の MAC アドレスなどの属性情報を含めることが可能 ENI を削除することなく EC2 リストアの際に MAC アドレスを引き継ぐことが可能 固定 MAC アドレスを設定して、ライセンスファイルを関連付けることが出来る VPC とサブネットのサイズ設定 各サブネットは CIDR ブロックの最初の 4 つの IP アドレスと最後の IP アドレスは使用できず、インスタンスに割り当てることが出来ない ELB はトラフィックスパイクのために拡張されると IP アドレスを消費する VPC の予約アドレス 0, 1, 2, 3, 255 が予約されている EC2 削除保護 有効にすると、削除保護を無効にしない限り、インスタンスを終了できなくなる IP マルチキャスト、IP ユニキャスト マルチキャスト(複数の相手にデータを送信) 単一の相手にデータを送信 同時に EC2 インスタンスに割り当てることが出来るのは 1 つの IAM ロールだけ RDS はスケーラブルでなく、費用対効果も高くない Beanstalk データベースを Elastic Beanstalk 環境に追加する 環境の一部となったデータベースは、環境のライフサイクルに固定される 一度追加すると環境から削除できず、環境を終了するとデータベースインスタンスも終了する ブルーグリーンデプロイメント Swap Environment URLs を使用してブルーグリーンデプロイを行う 同じ物理ホスト上で実行する必要があるライセンスを持つソフトウェアパッケージを実行する方法 ホストのアフィニティを Host に設定した Dedicatesd Host でインスタンスを実行する VPC に関連したインスタンスのテナンシー(テナント属性) default VPC で起動されたインスタンスはデフォルトで共有ハードウェアで実行される 他のアカウントと同居する dedicated VPC で起動されたインスタンスはデフォルトでハードウェア専有インスタンス ただし、インスタンスの起動時に host のテナントを明示的に指定しない場合 ハードウェア専有インスタンスとは ハードウェアレベルで物理的に分離されインスタンスが実行される VPN は接続をプライベートに保つのに役立ち、費用対効果が高く、プライベートサブネットにも配置できる インスタンスフリート スポットインスタンスを利用すると、予想外に終了する可能性があるが、インスタンスフリートを利用することで、高い予測性を保証する定義期間(スポットブロック)を使用できる。スポットインスタンスはその期間を過ぎると終了するが、期間が終了する前に中断されることはない データベースのシャード データベースにおける分割手法の一つで、データを複数のノードのディスクに分割配置することで、データベースへのリクエストを分散し全体のスループットを上げる目的で利用する AWS Snowball オンプレミスから Amazon S3 に大量のデータを転送するための迅速で費用対効果の高いオプションを提供する 80TB の容量を持つ物理アプライアンスを配送し、オンプレミス → クラウド間の回線に依存しないデータ転送を実現 運搬も含めると 10 日程度でデータ移行完了 10TB を超える DB を AWS に移行する方法 AWS Snowball を使用してデータを移行する DB インスタンスを起動する DB インスタンスに AWS Snowball から S3 経由でデータをロードする VPN を介してオンプレミスデータベースから DB インスタンスへデータベースのレプリケーションを設定 DNS を変更して DB インスタンスを指定する レプリケーションを停止する データ移行後、オンプレとレプリケーションを設定して AWS の DB インスタンスを同期させて切り替えることが出来る AWS Snowmobile 超大容量(PB ペタバイトサイズ)を AWS に移行するために使用するデータ転送サービス オンプレミスのデータセンターと AWS 間の接続について DirectConnect は実際の工事が必要になることから期間が必要なため、VPN 接続した後 DirectConnect するのが定石 デフォルトのルートは変更不可であり、ルーティングテーブルを使用して VPC 内のサブネット間のルーティングを制御することはできない 各ルートテーブルには、VPC 内で通信を有効にするローカルルートが含まれます。このルートは、デフォルトですべてのルートテーブルに追加されます。サブネットルートテーブルまたはメインルートテーブルでこれらのルートを変更または削除することはできません。 クロスネットワーク接続 クロスコネクトが 90 日以内に完了しない場合、LOA-CFA(letter of Authorization and Connecting Facility Assignment) が付与した権利は無効になる。有効期限が切れた LOA-CFA を更新するには、AWS Direct Connect コンソールから再度ダウンロードできる AWS 一括請求の利点 組織内のすべてのアカウントの使用量を結合し、リザーブドインスタンスの割引と料金のボリューム割引を両方活用できる AWS Organizations アカウントを作成すると、ルートアカウントに加えて、OrganizationAccountAccessRole ロールという管理者のアクセス許可を付与する IAM ロールが自動的に作成される マスターアカウントの IAM はスイッチロールして OrganizationAccountAccessRole を持ったユーザで切り替え先アカウントに入ることができる 組織ですべての機能を有効にして組織単位(OU)を作成し、その OU にサービスコントロールポリシー(SCP)を適用することを推奨 誤って主要なサービスからユーザーを締め出すことの無いように、アカウントを 1 度に少しづつ OU に移動する 組織の一括請求全体に適用されるリザーブドインスタンスの料金のメリット マスターアカウントのリザーブドインスタンスでリザーブドインスタンスの共有を有効にする(デフォルト設定) 組織配下の別のアカウントに一致する使用状況に対してリザーブドインスタンス割引が適用される 組織間のアカウント移動 古い組織から メンバーアカウントを削除する 新しい組織から招待を送る メンバーアカウントで新しい組織への招待を受け入れる 「createdBY」 タグ：誰がリソースを作成したかを追跡する AWS が定義するタグ マスターアカウントで「AWS generated tags」を有効化する タグを使用してリソースを整理し、コスト配分タグを使用して AWS のコストを詳細レベルで追跡する AWS には 2 つのタイプのコスト配分タグがある AWS generated tags AWS によって AWS generated tags が定義、作成適用される マスターアカウントで「AWS generated tags」を有効化する ユーザー定義タグ ユーザーが定義、作成、適用する SCP(Service Control Policy) SCP はユーザーの IAM ポリシーを制御しない。アカウントがどのアクションを定義するかのガードレールを定義するまで SCP を定義する さらに、ユーザーまたはロールに IAM ポリシーを追加して、実際にアクセス権限を付与する必要がある SCP と IAM のポリシー双方でアクションが許可されている場合のみ、アクセス許可される Amazon RDS on VMware データベースを AWS へ ワンクリックで実行できるレプリケーションを使い、オンプレミス databases → Amazon RDS onVMware → Amazon RDS と移行できる スポットインスタンスはリソースの確保を保証しない リザーブドインスタンスはピーク時以外でも利用する事になりコストが増える RDS への読み取りトラフィックにリードレプリカを使うことで DB インスタンスのパフォーマンスと耐久性が向上する ElastiCache のインメモリキャッシュを利用して、ネットワークのレイテンシを軽減し、データベースの負荷を軽減する ElastiCache は永続的なメタデータ情報の保存には適さない EFS(Elastic File System) EFS ボリュームが暗号化されていないことによってもたらされるセキュリティに対処するための措置 転送時の暗号化 ファイルシステムをマウントするとき、伝送中のデータの暗号化を有効にできる 保管時のデータの暗号化 EFS ファイルシステムを作成するときに有効にする EFS は S3 と比較して高価であり、CloudFront はオリジンとして EFS をサポートしていない AWS Rekognition イメージや保存済みのビデオから有名人を認識できる また、Lambda を使用するとスケーラブルでコスト効率の高いアプリケーション層が得られる Aurora サーバレス 予測不可能なワークロードに適する Amazon RDS on VMware 管理対象 オンプレミスのオペレーティングシステムとデータベースエンジンへのパッチ適用 オンプレミスと AWS 内両方のデータベースでの保持ポリシーに基づくオンラインバックアップ オンプレミスとクラウドのバックアップからのポイントインタイムの復元 オンプレミスと AWS 内でのリードレプリカ作成 データベースのストレージ CPU、メモリ のスケーリングが自動化 非サポート マルチ AZ 配置 AWS Server Migration Service(AWS SMS) オンプレミスの VMware vSphere, Microsoft Hyper-V/SVMM を AMI として AWS への移行を自動化する AMI として段階的にレプリケートし、EC2 にデプロイする Amazon Redshift Redshift はシングル AZ のみをサポートする Redshift クラスターは自動スナップショットを作成出来、障害が発生すると、S3 に保存されたスナップショットから新しい Redshift クラスターを作成出来る S3 より保管コストが高い Redshift のワークロード管理(WLM) いくつのクエリーキューが処理に利用可能か およびそれぞれのキューがどのようにそれらのキューにルーティングされるか キュー間でのメモリ配分 キューにおけるクエリータイムアウト設定 などを設定できる 6 つの一般的なアプリケーション移行ステージ リホスト(リフトとシフト)(Re-host) そのまま持っていく プラットフォーム再編(リフト、ティンカー、シフト)(Replatform) コアアーキテクチャを変更することなくいくつかクラウド最適化する DB のマネージドサービスへの移行、あるいは Elastic Beanstalk のような完全マネージド型プラットフォームへのアプリの移行 再購入(ドロップアンドショップ)(Replace) 別の製品を購入する リファクタリング／再設計(Refactor) この解決策は元も高コスト 使用停止(Retire) 保持(Retain) AWS Trusted Advisor 使用率とコスト削減のチェック リアルタイムアラートは提供しない Trusted Advisor で全ての項目をチェックするためには、ビジネスサポートプラン以上を契約する必要がある CloudWatch + Lambda + SNS は、TrustedAdvisor サービスの制限値の確認、監視、通知に役立つ CloudWatch Events をトリガーにした S3 オブジェクト ACL の自動検出および修正 S3 のオブジェクトレベルのログを有効にする CloudTrail ログでパブリック読み取りアクセス許可を持つ PutObjec API 呼び出しが検出されたときに、SNS トピックを使用して通知するように Amazon CloudWatch Events を設定する AWS Labmda 関数を呼び出して S3 バケットを保護する Amazon CloudWatch Events ルールを設定する クラスタープレイスメントグループと拡張ネットワーキング クラスタープレイスメントグループは、単一のアベイラビリティゾーン内のインスタンスを論理的にグループ化したもの。低ネットワークレイテンシー、高ネットワークスループット、またはその両方から利点が得られるアプリケーションや、ネットワークトラフィックの大部分がグループのインスタンス間で発生する場合、クラスタープレイスメントグループが推奨される プレイスメントグループへの既存のインスタンスの移動、別のプレイスメントグループへのインスタンスの移動、またはプレイスメントグループからのインスタンスの削除を行うことが出来る。インスタンスの削除をする必要はなく、Stopped 状態にすればプレイスメントグループに移動できる 拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケットの高いパフォーマンス、常に低いインスタンス間レイテンシーを実現する プレイスメントグループには 1 つのアカウントの 1 リージョン内で固有の名前を付ける必要がある AWS Application Discovery Service サーバーのホスト名、IP アドレス、MAC アドレス、CPU 割り当て、ネットワークスループット、メモリ割り当て、ディスクリソース割り当てといった静的設定内容を含む様々なデータが収集される CPU 使用率やメモリ使用率といったリソース使用率のメトリクスも収集できる Amazon Athena は、標準 SQL を使用して、Amazon S3 でのデータの直接分析を可視化するインタラクティブなクエリサービス DDoS およびアプリケーションレイヤーの攻撃からの保護 Route53 を使用した AWS Shield と、 CloudFront を使用した AWS WAF は EC2 インスタンスを DDoS およびアプリケーションレイヤーの攻撃から保護する ELB ALB レイヤー 7 のトラフィックのみで機能する NLB プロトコルが HTTP(S)以外の TCP または UDP の場合、こちら一択 レイヤー 4 のトラフィックのみで機能する WAF はアタッチ出来ない AWS Schema Conversion Tool(AWS SCT) セカンダリインデックス、シーケンス、ストアドプロシージャ、トリガー、シノニム、ビューなど)を AWS の DB に移行する データベースエンジン間で既存のデータベーススキーマを変換できる ソースデータベース：ターゲットデータべース SQL Server → RDS MySQL, PostgeSQL, Aurora PostgreSQL etc Oracle → Aurora MySQL, Aurora PostgreSQL, MySQL, Oracle, PostgreSQL etc AWS Database Migration Service(AWS DMS) データを移行するサービス リレーショナルデータベースサービスなどのデータストアの移行に使用できるウェブサービス 1 回限りの移行を実施でき、継続的な変更をレプリケートしてソースとターゲットの同期を維持することが出来る データに関係ない(セカンダリインデックス、シーケンス、ストアドプロシージャ、トリガー、シノニム、ビューなど)は移行しない 唯一の要件はエンドポイントの一つが AWS のサービス上にあること AWS DMS を使用して、オンプレミスのデータベースから別のオンプレミスのデータベースに移行することはできない Elasticsearch のソースはサポートしない データベースエンジンを変更する場合の流れ ローカルで AWS Schema Conversion Tool(AWS SCT)を使用してデータベーススキーマを新しいプラットフォームに変換 残るはデータのみになる 次に、AWS DMS を使用してデータをターゲットデータベースへ移行する Amazon Connect は呼び出しの受信、コンタクトフローの作成、処理の拡張に対応できる Amazon Lex を対応フローに組み入れることで、自然応答が自然な会話に変わる Amazon lex 音声やテキストを使用して、任意のアプリケーションに対話型インターフェイスを構築する CloudFormation テンプレート スタックの設計図 どのリソースを構築するか(状態)を記述 リソースの依存関係は AWS Cloudformation が自動判別 スタック 単一のユニットとして管理できる AWS リソースのグループ スタックポリシー スタックの更新中にスタックのリソースが意図せずに変更/削除されるのを防ぐ 指定したリソースに対して実行できるアクションを定義する JSON ドキュメント 例) RDS リソースに対する変更を禁止するポリシー 使用できる主なセクション Description テンプレートの説明 Parameters テンプレートに渡す値 Mappings キーと値のテーブル Conditions リソース作成などを制御する条件 Resources スタックの起動するリソースやプロパティを指定 Outputs スタック構築後に表示・取得した値や他スタックとの連携の為の出力を指定 組み込み関数 Ref 指定したパラメータまたはリソースの値を返す Fn::Join 一連の値を特定の区切り文字で区切って 1 つの値に追加 Fn::GesAZs 指定されたリージョンのアベイラビリティゾーンを含んだ配列を返す Elastic Beanstalk, Step Functions は CloudFormation に依存してリソースをプロビジョニングする 誤ってリソースを削除させないためには、DeletionPolicy 属性を使用する クロススタック参照 あるスタックから別のスタックへリソースをエクスポートする 必要なリソース出力を他のスタックから参照でき、1 つのスタックに全てのリソースを含めなくてよくなる IAM ポリシーを使用して、タグ付けされた AMI からのみ EC2 インスタンスを起動するようにユーザーまたはサービスを制限できる AWS Config を使用して、未承認の AMI で起動されたインスタンスをチェックするルールを定義できる Amazon Inspector 自動セキュリティ診断サービス EC2 にエージェントを導入し、プラットフォームの脆弱性を診断するホスト型診断サービス ルールパッケージ CVE(Common Vulnerabilities&Exposures 共通脆弱性識別子) CIS(Center for Internet Security) 米国のインターネットセキュリティ標準化団体 OS のセキュリティベンチマーク セキュリティのベストプラクティス 実行時の振る舞い分析 AWS Lambda 関数のパフォーマンス向上 実行コンテキストの再利用を活用して関数のパフォーマンスを向上させる 関数の同じインスタンスで処理された後続の呼び出しは、これらのリソースを再利用できる Lambda では、構成されているメモリの量に比例して CPU パワーが直線的に割り当てられる Transit VPC グローバルネットワーク中継センターを作成するために、地理的に分散した複数の VPC を接続する戦略 オンプレミスがリージョンを超えて VPC に接続することまではサポートしない 今後は Transit Gateway 　を使うので覚えなくても良いかも Transit Gateway VPC とオンプレミスネットワークを単一のゲートウェイに接続できるようにするサービス AWS SAM を使用して、サーバレスアプリケーションをデプロイする場合、組み込みの CodeDeploy を使用して新しいバージョンの Lambda 関数をデプロイし、徐々にトラフィックを新しいバージョンにシフトし、コードを検証することができる Amazon EBS-backed AMI を使用するインスタンスの場合、インスタンスを停止して再起動することで、障害が発生したホストから正常なホストへと切り替わり、障害を復旧させることが出来る インスタンスの再起動ではホストが変更されない vpc エンドポイントから S3 へのアクセス制限のベストプラクティス 特定のバケット(awsexamplebucket1)に対するアクセスを vpc エンドポイント ID が vpce-1a2b3c4d からのアクセス以外は拒否に制限するポリシーを設定する { "Version": "2012-10-17", "Id": "Policy1415115909152", "Statement": [ { "Sid": "Access-to-specific-VPCE-only", "Principal": "*", "Action": "s3:*", "Effect": "Deny", "Resource": [ "arn:aws:s3:::awsexamplebucket1", "arn:aws:s3:::awsexamplebucket1/*" ], "Condition": { "StringNotEquals": { "aws:SourceVpce": "vpce-1a2b3c4d" } } } ] } Amazon Aurora Global Database 複数の AWS リージョンにまたがり、低レイテンシーのグローバル読み取りを可能にする 1 つのリージョンにプライマリ(読み書き操作) DB クラスターがあり、異なるリージョンにセカンダリ(読み取り専用) DB クラスターがある API Gateway API キャッシュを有効にすると、Lambda 関数の呼び出し回数を減らせる AWS Glue AWS Glue は、分析、機械学習、アプリケーション開発のためのデータの検出、準備、結合を簡単に行える、サーバーレスデータ統合サービス