【AWS SOA 備忘録】 問題集を解いていて、個人的にややこしく感じたところです。 試験前に見返す用でもあります。 AWS Config AWS CloudFormationスタックをサポートすることができる。 CloudFormationの現在と過去の構成の追跡を開始して、スタック構成が変更された時にAmazon SNS経由で通知を受け取れる。 Configルールを使用して、CloudFormationスタックがSNSトピックにイベント通知を送信しているか確認することも可能。 AWS Artifact 重要なコンプライアンス関連情報の頼りになる一元管理型のリソース ユーザーとの契約にかかる文章の他、AWS独自のコンプライアンス対応に関するレポートが提供される。 AWS Trusted Advisor AWSインフラストラクチャサービスを監視して、既知のベストプラクティスと比較する。 そして、節約やシステムパフォーマンス、セキュリティの観点からチェックするプログラム Amazon Inspector AWSが提供する脆弱性診断を行うサービス エージェントを利用したプラットフォーム診断のためのサービス

はじめに やまだゆう（@yamaday0u）です。 ぼくは現在、業界未経験で、エンジニアへの転職を目指して勉強・転職活動中です。 先日、AWSを使ったオリジナルアプリのSSL化に成功しました。 参考にしたサイトでは、SSL化を実現する方法として以下の説明をしていました。 Route53で取得したドメインを使ってACMでドメイン証明書を取得し、その証明書をALBに適用する。 ALBとEC2を紐付けてインターネットからはALBに対してHTTPSで通信を行い、ALBからEC2にはHTTPでトラフィックを転送する。 【初心者向け】AWSのサービスを使ってWebサーバーをHTTPS化する（DevlopoersIO produced by Classmethod）より 正直、この説明への理解があいまいなままで、言われた通りの手順でどうにか実装できたのですが エンジニアを目指している以上、あいまいな理解をそのまま放っておいてはいけないと思い、理解を深めるため、記事にまとめることにしました。 SSL化の実現方法 EC2を使いデプロイ済みのアプリと、AWSが提供するサービスのみを使ってSSL化します。 使用したAWSのサービス 役割 Amazon Route53 可用性と拡張性に優れたクラウドのドメインネームシステム (DNS) ウェブサービスを提供する AWS Certificate Manager SSL/TLS証明書の提供、管理、デプロイを簡単にする Elastic Load Balancing アプリケーションへのトラフィックを複数のターゲット (今回はAmazon EC2 インスタンス) に自動的に分散するこのサービスのうち、Application Load Balancerを使用 1.Amazon Route53とは 簡単にいえばドメイン名の登録やドメインネームシステム（DNS）を提供してくれるサービスです。 ドメインネームシステム（DNS） ドメインとIPアドレスを対応させるシステム（IT用語辞典e-Wordsより） さらに新しい用語が出てきたので調べました。 IPアドレス（Internet Protocol Address） インターネットなどのTCP/IPネットワークに接続されたコンピュータや通信機器の一台ごとに割り当てられた識別番号（IT用語辞典e-Wordsより） ざっくり言えば、ネットワーク上の住所のようなもので、個々のコンピュータを識別するためのアドレスです。 100.10.0.1のような10進数の数字で表されます。 ドメイン名 インターネット上に存在するコンピュータやネットワークを識別し、階層的に管理するために登録された名前のこと（IT用語辞典e-Wordsより） 数字の羅列であるIPアドレスは、人間が覚えるのに困難なため、https://www.google.com/のように覚えやすい名前（ドメイン名）を作りIPアドレスと紐づけて運用します。 したがってRoute53は、ドメイン名の登録と、後述のロードバランサーのDNS名とドメイン名を紐づける役割を担います。 ちなみにぼくの場合、このRoute53でオリジナルアプリのドメイン名となるgroup-calendar.netを登録しました。 2.AWS Certificate Manager（ACM）とは SSL/TLS認証をしてくれるサービスです。 SSL/TLS認証については、ぼくが過去に初心者目線でまとめた記事がありますので、こちらも読んでみてください。 Route53で登録したドメインに対してSSL/TLS認証で保護します。 3.Elastic Load Balancing（ELB）とは AWSが提供するロードバランサーのサービスです。 ロードバランサー（load balancer）/負荷分散装置 通信制御装置の一つで、外部から送られてくるデータや処理要求を、同等に機能する複数のシステムに振り分け、一台あたりの負荷を抑える装置（IT用語辞典e-Wordsより） 特定のサーバーにアクセスが集中してダウンすることを防いだり、特定のサーバーのメンテナンス時にリクエストが送られてこないようにしたりする際に、このロードバランサーが活躍します。 個人で作る小規模なアプリでは、上記の恩恵はあまり感じられませんが、今回のロードバランサーの役割は以下の2点です。 インターネットからHTTPS通信を受ける EC2インスタンスにHTTP通信を送る 簡単にいうと、インターネットとサーバー（EC2）の間に入ってインターネットからHTTPS通信を受ける役割を担います。 複数のサーバーを使う大規模なアプリの場合、HTTPS通信をロードバランサーで一手に引き受けることで、本来各サーバーごとに必要なSSL/TLS証明書がロードバランサー1つの分で済んでしまうメリットがあります。 ロードバランサーの種類 ELBでは以下の4つのロードバランサーを提供しています。 特徴は ELBの公式より抜粋。 種類 特徴 Application Load Balancer HTTP トラフィックおよび HTTPS トラフィックの負荷分散に最適 Network Load Balancer きわめて高いパフォーマンスが要求される TCP、UDPおよびTLSにおけるトラフィックの負荷分散に最適 Gateway Load Balancer サードパーティーの仮想ネットワークアプライアンスを簡単にデプロイ、拡張、および実行 Classic Load Balancer EC2-Classic ネットワーク内に構築されたアプリケーションを対象 ここの理解は今回は諦めました... 以下の記事が詳しく書いてありそうなので共有しておきます。 Elastic Load Balancing（Qiita） 個人開発のアプリでHTTP/HTTPS通信をするなら1番めのApplication Load Balancerを選択しておくというくらいの認識をしておくと良いと思います。 最後に 以上、簡単ですがSSL化で利用した技術について整理してみました。 用語の意味と技術の役割について少し理解が深まったと思います。 参考資料 【初心者向け】AWSのサービスを使ってWebサーバーをHTTPS化する（DevlopoersIO produced by Classmethod） Webサービスの安定稼働に欠かせない AWS ELBの基礎知識（NTT東日本） IT用語辞典e-Words Elastic Load Balancing（Qiita）

初めに 先日こちらの記事に FSx for Lustre ではレプリケートされたオブジェクトをインポートできなかったことを書きました。今回 Storage Gateway でも同様にレプリケートされたオブジェクトにアクセスできないという現象が発生しました。原因はレプリケーションに使用している KMS キーのアクセス権限がなかったことです。 検証結果 KMS の権限なしで以下のようにステータスがレプリカのオブジェクトにアクセスしてみます。 [ec2-user@ip-172-31-43-17 ~]$ aws s3api head-object --bucket account-a-bucket-0525 --key test_upload_4.txt --version-id JQnupBy2kZdOxhFHZ5v9VU9cvknOKOeA | grep 'ReplicationStatus' "ReplicationStatus": "REPLICA", [ec2-user@ip-172-31-43-17 ~]$ cat dir/test_upload_4.txt cat: dir/test_upload_4.txt: Input/output error アクセスできません。 KMSの権限ありの場合にアクセスしてみます。 [ec2-user@ip-172-31-43-17 ~]$ aws s3api head-object --bucket account-a-bucket-0525 --key test_upload_4.txt --version-id JQnupBy2kZdOxhFHZ5v9VU9cvknOKOeA | grep 'ReplicationStatus' "ReplicationStatus": "REPLICA", [ec2-user@ip-172-31-43-17 ~]$ cat dir/test_upload_4.txt test upload アクセスできました。 なお、ファイル共有作成時でもマウント後でもロールに KMS の権限を付与すればレプリケーションオブジェクトにアクセス可能です。

はじめに AWSを学ぶのにオススメな公式のハンズオンやチュートリアルのリンクを掲載しています。 ここにあるリンクは、個人的にオススメなだけであって、これをやればAWSを完全に使いこなせるようになることを保証するものではありません。 Workshop系 AWS Workshops このウェブサイトには、アマゾンウェブサービス（AWS）のチームによって作成されたワークショップがリストされています。ワークショップは、ビジネス上の問題を解決するために使用できる実践的なスキル、テクニック、または概念を教えたり紹介したりするために設計された実践的なイベントです。 このワークショップでは、VPCとサブネットの基本から、セキュリティとモニタリングの例を含む、トランジットゲートウェイとVPNを使用した高度な構成まで、AWSネットワーキングの全範囲をカバーしています。 このワークショップでは、DynamoDBテーブルからアイテムを作成、読み取り、更新、削除するCRUDAPIを作成します。 APIはサーバーレスで実行されるため、基盤となるインフラストラクチャの管理はなく、スケーリングは自動的に行われます。 AWSでAPIを作成するのがいかに簡単かをすべて45分以内で学びます。 アプリケーションモダナイゼーションイマージョンデーでは、一般的なクラウド移行の推進要因、メリット、課題について説明します。これには、モノリスアプリケーションを分解し、クラウドネイティブサービスを活用してクラウドが提供する最大限の価値を活用しながら、再アーキテクチャを通じて段階的に最新化するために利用できるストラングラーなどのパターンが含まれます。参加者は、モノリシックアプリケーションを立ち上げ、それをマイクロサービスに分解することを実際に体験します。 このワークショップでは、Amazon Web Services（AWS）を使用したTypeScriptプログラミング言語の基本について説明します。 このワークショップでは、App2Containerを使用してJavaまたは.NETアプリケーションを最新化します。アプリケーションごとに; App2Containerを使用して、アプリケーションを分析、コンテナ化、Amazon ECS（Elastic Container Service）およびデータベース移行サービス（DMS）またはネイティブバックアップ移行ツールにデプロイして、データベースをAWS RDS（リレーショナルデータベースサービス）に移行します。 Amazon Elastic ContainerServiceの基本的な機能と使用法の概要 ECS Fargate Workshop Amazon AuroraPostgreSQLの機能と高度な機能を理解するのに役立つハンズオンワークショップラボコンテンツのコレクション このワークショップでは、VPCエンドポイントを活用してVPCをサポートされているAWSサービスにプライベートに接続し、ネットワークおよびIAMベースのセキュリティ構成を使用してAWSリソースとデータへのアクセスを制限する方法を学習します。 実践的チュートリアル 最初のアプリケーションをステップバイステップで立ち上げられる、チュートリアルをご用意しています。 モダンウェブアプリケーションを構築する IDE からのサーバーレスアプリケーションをローカルでデバッグ builders.flash builders.flash は、日本のソリューションアーキテクトによる身近なテーマで実践的なクラウドベストプラクティスを解説する記事や、幅広い開発インタビューをお届けする AWS のデベロッパー向けウェブマガジンです。メールメンバーに登録することで限定の特典を受け取ることができます。 AWSアイコン アーキテクチャダイアグラムを構築するための AWS 公式アイコンセット 英語サイトの方が更新が早いので、言語を英語にしてからダウンロードすると、日本語サイトで公開前のパワポがダウロードできることがあります 日本語サイトからダウンロードできるパワポも英語です AWS Loft 2018 年 10 月に東京の目黒にオープンした、スタートアップとデベロッパーのための施設です。 有効な AWS アカウント ID をお持ちのスタートアップ企業に所属している方々、企業内外でデベロッパーをされている方向けのコ・ワーキングスペースです。 2021 年現在、Online Ask an Expert の提供、ウェビナーでの情報発信をしています。 たまにオンラインセッションもやってるみたいです AWSome Day 「AWSome Day」は、AWS クラウドジャーニーのはじめの一歩として、AWS に関する基礎知識を 1 日で体系的に学ぶ無償のトレーニングイベントです。AWS テクニカルインストラクターが主導するセッションを通じて、コンピューティング、ストレージ、データベース、ネットワークといった AWS の主要なサービスを段階的に学ぶことができます。また、AWSに関わる方への基礎知識として、請求、アカウントマネジメント、料金モデル等、実際の導入に向けた内容となっております。技術的な面だけではなく、これから AWS クラウドを学ぶために必要となる知識を身に付けたい方、エンジニアのみならず、営業職、プリセールス職、学生まで幅広い方々におすすめします。

はじめに 基本的な構築方法は省略 ルーティング問題 URLを/foo /bar の用に Router系でパス指定した場合、ローカルやNginx等では動いてたのにCloudFrontだと、403エラーになるという問題が起きる。これを回避するために CloudFrontで403エラーが発生したら /index.html に転送するという方法がよく行われている(というか自分もVue Routerで下記などの事例を参考に適用していた)。 なんでも200 OK問題 ファビコンをちゃんと用意してないとブラウザーが/favicon.icoを引っ張ってくるが/index.htmlのHTMLが転送される。(まあ、アイコンとして表示されないけど気持ち悪い) 脆弱性検知ツール等がデバッグ用とか管理用のファイルとかのよくあるパスでアクセスしてきて、それに対して200で応答を返すので、そのファイル消したほうが良いって警告される。(まあ、そういうもんだって話ですが、監査を受けると説明しなきゃいけない) foo.png bar.js hage.css とかなんでも/index.htmlのHTMLなのはどうなのか…。 CloudFront Functions AWS samplesにそれっぽいものがある / -> /index.html と /foo/ -> /foo/index.html って書き換えなので、上記のような書き換えだとうまく行かない。 なので、上記をベースに拡張子なし=ルーティングされたもの、と言う判断で書き換えれば良い。 function handler(event) { var request = event.request; var uri = request.uri; // Check whether the URI is missing a file extension. if (!uri.includes('.')) { request.uri = "/index.html"; } return request; } Terraform resource "aws_cloudfront_function" "test" { name = "test" runtime = "cloudfront-js-1.0" comment = "my function" publish = true code = file("${path.module}/function.js") } resource "aws_cloudfront_distribution" "example" { # 省略 default_cache_behavior { # 省略 function_association { event_type = "viewer-request" function_arn = aws_cloudfront_function.test.arn } } # 省略 }

1.はじめに AWSの提供する負荷分散サービスであるELBの中で、レイヤー4に対応し、TCP/UDPトラフィックの負荷分散を行うNLBの構築手順について解説します。 ELBの構築手順はAWSサービスの中でも簡単な方ですが、やはり一度構築を経験しておくことは、業務等で素早くELBを立てなければならない場合にとてもスムーズに構築できるようになるのでおすすめです。 では、早速構築手順について解説していきたいと思います。 2.概要 《本記事の流れ》 手順１：ターゲットグループの作成 手順２：NLBの作成 手順３：動作確認 前提事項：最低限インターネットと通信できるEC2インスタンスを2, 3つ作成しておくこと 《本記事の目標》 NLBを構築し、複数のEC2インスタンスへのトラフィックを負荷分散する 3.ターゲットグループ NLBの作成前にまずはNLBに紐付けるターゲットグループを作成します。 AWSマネジメントコンソールの上部検索窓にて、『EC2』と検索します。 サービスの下に表示される『EC2』をクリックし、EC2マネジメントコンソールを開きます。 EC2マネジメントコンソールの左ペインを下にスクロールし、『ロードバランシング』＞『ターゲットグループ』をクリックし、ターゲットグループマネジメントコンソールを開きます。 ターゲットグループマネジメントコンソールにて、右上の『Create Target Group』をクリックし、TG作成画面に進みます。 【グループの詳細を指定する】 《基本構成》 負荷分散するターゲットの基本構成を設定します。 以下のパラメータを設定してください。 '************************************************** ・ターゲットタイプを選択してください ⇒ 『インスタンス』 ・ターゲットタイプグループ名 ⇒ ※任意の名前を入力してください ・プロトコル：ポート ⇒ HTTP：80 ・VPC ⇒ ※ターゲットのインスタンスが所属するVPCを選択して下さい ・プロトコルバージョン ⇒ HTTP1 '************************************************** 《ヘルスチェック》 デフォルトのままで問題ありません。 《タグ》 デフォルトのままで問題ありません。 【ターゲットを登録する】 《利用可能なインスタンス》 ターゲットへ登録可能なインスタンスの一覧が表示されるので、負荷分散させるインスタンスにチェックを入れ、『Include as pending below』ボタンをクリックしてください。 《Targets (*)》 ターゲットへ登録するインスタンス一覧が表示されます。 確認し、問題がなければ右下の『Next』をクリックし、ターゲットグループを作成します。 4.NLB ではNLBの作成に入ります。 EC2マネジメントコンソールの左ペインを下にスクロールし、『ロードバランシング』＞『ロードバランサー』をクリックし、LBマネジメントコンソールを開きます。 LBマネジメントコンソールにて、左上の『ロードバランサー』をクリックし、LB作成画面に進みます。 【ロードバランサーの種類の選択】 この画面では、作成するLBのタイプを選択します。 LBの種類は『Network Load Balancer』を選択します。 【ネットワークロードバランサーを作成する】 《基本構成》 ロードバランサーの基本構成を設定します。 以下のパラメータを設定してください。 '************************************************** ・ロードバランサー名 ⇒ ※任意の名前を入力してください ・スキーム ⇒ インターネット向け ・IPアドレスタイプ ⇒ IPv4 '************************************************** 《ネットワークマッピング》 NLBとどのネットワーク帯をマッピングするかを設定します。 ターゲットグループ作成時にターゲットに追加した対象リソースが所属しているVPC、サブネットを指定してください。 《リスナーとルーティング》 ここではターゲットグループを指定します。 先程作成したターゲットグループを指定し、プロトコルとポートはそれに合わせて設定してください。 《概要》 上記手順で設定したパラメータがまとめて表示されますので、今一度間違いがないか確認してください。 確認の結果問題なければ、右下の『ロードバランサーを作成する』をクリックしてください。 ロードバランサーマネジメントコンソールに戻りますので、作成したLBが表示されていることを確認してください。 5.まとめ 以上がNLBの構築手順になります。 大した手順ではないですが、一度構築をしたことがあるのかないのかでは実務での作業において大きな差が出ます。 インフラに身を置くものでしたら数回程度はNLBで遊んでおくことをおすすめします。

やりたいこと オンプレミス環境や社外の対外接続先などとAWS環境を接続するにあたってIPsecVPNを利用するケースがあるが、その場合に困ることとして対外接続先と接続するまでIPsec周りを使ったテストを自社内で完結できないという点が挙げられる。 AWSアカウントの中で2つのVPCを立ててIPsecVPNを構成することができればその課題を解消できるということで、その方法について検討・実装をしてみた。 なお、通常このような場合には片方のVPCのEC2上にソフトウェアVPN（VyOSなど）を立てて実現するパターンもあるが、検証目的の場合、できるだけ早く・安く実装することが望ましいため今回はAWSのマネージド機能のみで実装できる方法で実現している。 文字に起こすと複雑に見えるが、環境自体の構築は除いてVPN接続のみでいうと30分もあれば実装可能。 実装イメージ 留意事項 ・ CIDRはあくまで記載上の例。プライベートアドレスであれば何でも良い ・ 上図のイメージは同一AWSアカウントの中に複数VPCを設ける想定にしているが、別AWSアカウントのVPCでも同じ対応が可能 実装手順 概要説明 両方のVPCにVPN接続を作成し、そのVPN接続の設定を合わせることでトンネルを確立する AWSのVPN接続では対抗先（通常はオンプレ）をカスタマーゲートウェイとして設定する必要があるが、今回はそのカスタマーゲートウェイに相手型VPCのVPNで利用しているIPアドレスを設定する IPsecを確立する際に必要な鍵情報としてPreSharedKey（事前共有キー）があるので、これは両方のVPCのVPN接続で同一のものを利用する 通常AWSとオンプレ間の接続においてはオンプレ側からAWSに対して接続のネゴシエーションを行うが、今回はAWS同士なのでVPNトンネルオプションのスタートアップアクションでネゴシエーションを明示的に行う 具体的な設定手順の説明 環境準備（VPC/Subnet/SG/RouteTable/VGW/EC2の作成） ここに関してはAWS上での基本的な環境構築であり今回の主題から外れるため概要の記載に留める 1. AWSアカウント上でVPCを2つ作成、その中にPrivateSubnetを設ける 2. 通信させたい対象となるコンポーネントを作成する（上図ではEC2を2台作成し、片方にNginxを搭載してVPC1側からVPC2側にHTTP通信ができること想定） 3. VPC1,2の両方にVirtual Private Gatewayを作成・アタッチする 4. Route Table/Security Groupに必要な設定を実施する 留意事項： ・ 通信したい双方のSubnetのRouteTableでVGW向けのルート設定を行うこと。 　（上図の例ではVPC1側のRouteTableに10.128.0.0/24でVGWを向くように設定、VPC2側のRoutetTableに10.0.0.0/24でVGWを向くように設定） ・ 通信を行うEC2にアタッチしているSecurityGroupで対抗先の情報をInbound/Outboundのルールに設定すること。 IPsecVPNの設定その1 VPC1（10.0.0.0/16)側のVPN設定 以下の作業は基本的にマネジメントコンソール上、VPCのメニューから行う。 仮想プライベートネットワーク（VPN）のカスタマーゲートウェイを選択し、カスタマーゲートウェイの作成を行う。 名前：任意（後で削除するので何でも良い） ルーティング：静的 IPアドレス：任意（後で変更するので1.1.1.1のようなものでOK） Certificate ARN：指定しない Device：指定しない サイト間のVPN接続を選択し、VPN接続の作成を行う。 名前：任意（用途が分かるようにはしておく） ターゲットゲートウェイタイプ：仮想プライベートゲートウェイ 仮想プライベートゲートウェイ：環境準備の手順3で作成したVGWのうち、VPC1にアタッチしたものを選択 カスタマーゲートウェイ：既存 カスタマーゲートウェイID：手順1で作成したCGWを選択 上記以外はデフォルト　OR 空白のままでOK しばらく待って作成したVPNの状態が「使用可能」になったら対象のVPNを選択して「設定のダウンロード」を実施→ベンダーやプラットフォーム・ソフトウェアはなんでも良い ダウロードした設定をテキストで開き、「PreShared」もしくは「Shared」というキーワードで検索、32桁ぐらいのランダム文字列があるのでその文字列を記録する　・・・　PreShared Key VPN接続の中の「トンネル詳細」タブを選択し、トンネル番号1の「外部IPアドレス」を記録する　・・・　VPC1の接続先IP IPsecVPNの設定その2 VPC2（10.128.0.0/16)側のVPN設定 カスタマーゲートウェイの作成を行う 名前：任意（用途が分かるようにはしておく） ルーティング：静的 IPアドレス：「IPsecVPNの設定その1 VPC1（10.0.0.0/16)側のVPN設定」の手順5で記録したVPC1の接続先IPを入力 その他は指定せずにOK VPN接続の作成を行う 名前：任意（用途が分かるようにはしておく） ターゲットゲートウェイタイプ：仮想プライベートゲートウェイ 仮想プライベートゲートウェイ：環境準備の手順3で作成したVGWのうち、VPC2にアタッチしたものを選択 カスタマーゲートウェイ：既存 カスタマーゲートウェイID：手順1で作成したCGWを選択 トンネル内オプション　トンネル1の事前共有キー：「IPsecVPNの設定その1 VPC1（10.0.0.0/16)側のVPN設定」の手順4で記録したPreShared Keyを入力 上記以外はデフォルト　OR 空白のままでOK しばらく待って作成したVPNの状態が「使用可能」になったら対象のVPNを選択して「設定のダウンロード」を実施 ダウンロードした設定をテキストを開き、「PreShared」もしくは「Shared」というキーワードで検索、そこで表示される32桁ぐらいの文字列が先ほど入力したPreShared Keyの文字列に一致していることを確認 VPN接続の中の「トンネル詳細」タブを選択し、トンネル番号1の「外部IPアドレス」を記録する　・・・　VPC2の接続先IP IPsecVPNの設定その3 VPC1（10.0.0.0/16)側のVPN設定修正 カスタマーゲートウェイの作成を行う 名前：任意（用途が分かるようにはしておく） ルーティング：静的 IPアドレス：「IPsecVPNの設定その2 VPC2（10.128.0.0/16)側のVPN設定」の手順5で記録したVPC2の接続先IPを指定 Certificate ARN：指定しない Device：指定しない 「IPsecVPNの設定その1 VPC1（10.0.0.0/16)側のVPN設定」の手順2で作成したVPNを選択し、アクションから「VPN接続を変更」を選択、ターゲットタイプ「Customer Gateway」、ターゲットカスタマーゲートウェイとして手順1で作成したカスタマーゲートウェイを選択する 手順2で選択したのと同じVPNに対してアクションから「VPNトンネルオプションを変更」を選択、対象のVPNトンネルとしてトンネル番号1のIPアドレスを選択して、「スタートアップアクション」で開始を選択して保存 上記を行なってしばらくしてVPNの状態が「使用可能」になったらVPC1・2両方のトンネル詳細タブを確認、うまくいっていればトンネル番号1のステータスがアップになっているはず！ 以上で接続できる状態になっているので、VPC1上のEC2からVPC2上のEC2（Nginx）にCurlコマンドなどを実行すれば応答が得られる。 なお、VPN接続は2経路用意されているが、トンネル番号2同士の接続については、カスタマーゲートウェイで設定できるのが1つのIPしかなく、それをトンネル番号1で使ってしまっているためできない。 注意事項 今回紹介した方法について、AWSサポートに問い合わせたところ「サイト間VPNはオンプレミとVPCの間での接続を行う機能として提供されており、サイト間VPN接続同士を接続することは想定するご利用形態には含まれておりません」と回答を受けている。 この方法を業務の中で利用した場合、意図しない挙動となるリスクもあるため、あくまで開発環境でのテスト程度で利用するに留め、本番業務の中では利用しないことを推奨する。 本番業務においてAWSのVPC同士を接続したい場合にはPeeringもしくはPriateLinkなどAWSが用意している機能を素直に使うのが良い。 参考URL

■この記事を読む対象者 docker初学者向けの記事です。 ■環境 Amazon Linux2 ■エラーが起きたあらまし dockerのドキュメント（https://matsuand.github.io/docs.docker.jp.onthefly/engine/install/linux-postinstall/）　　 を見つつdocker設定　→　起動しようとしたら『docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?』と出て、一向にdockerを起動できなくなってしまったので、その時の対応履歴を残します。 ■原因 まず、今回どうしてこのエラーが発生してしまったか？　ですが、dockerのドキュメントに沿って、docker起動どうやってたっけ・・・と調べつつ進めていると、なぜか知らないうちにdockerのリモートアクセスの設定を行っていました。 今回のエラーの原因はdockerの外部アクセスを許可するための設定（リモートアクセス）で /etc/docker/の配下にdaemon.jsonを作成していました。 また、sudo systemctl edit docker.service　コマンドで、これまたリモートアクセスをしていました。 つまり、リモートアクセスしないのに、２重でリモートアクセスの設定を行っていました。 ■対処方法 /etc/docker/の配下に作成していたdaemon.jsonファイルを削除。 sudo systemctl edit docker.service　コマンドをもう一度行い、ファイルの中身を綺麗に消しました。 あとは sudo service docker stop して sudo service docker start で再度dockerを起動 sudo docker run hello-world コンテナ作成 docker info でもdockerが起動できたことが確認できます。 ■おわり この記事がお役に立ったら幸いです。 どこか間違っている箇所ありましたらご指摘ください。

事前 大阪リージョンのAWS Backupに"Default"というバックアップボルトがある前提です。デフォルトであるのでだいじょぶだと思う デフォルトサービスロールを作っておく。"AWSBackupDefaultServiceRole" これは、この手順で作るか、このブログ のようにAWS Backupで一度オンデマンドバックアップを行うと自動で作ることも可能。この方が楽です。 サンプルテンプレート test-vault という名前のバックアップボールトを作成します。 test-plan という名前のバックアッププランを作成します。 ボールト test-vault に保存するバックアップを設定します。 test-rule という名前のバックアップルールを作成し、毎日 1 回のバックアップを実行するようスケジュールします。これらのバックアップは、作成後 2 日で削除されるように設定します。 災害復旧の目的でバックアップを ap-norteast-3 AWS リージョンにコピーするように CopyAction を設定します。これらのバックアップは、作成後 2 日で削除されるように設定します。 AWSBackupDefaultServiceRole という名前の IAM ロールを使用して、バックアップジョブを実行します。 キー backup2 と値 true でタグ付けされたすべてのリソースにバックアッププランを割り当てます。 AWSTemplateFormatVersion: "2010-09-09" Description: "Backup Plan template for thin backups" Resources: testvault: Type: "AWS::Backup::BackupVault" Properties: BackupVaultName: "test-vault" testplan: Type: "AWS::Backup::BackupPlan" Properties: BackupPlan: BackupPlanName: "test-plan" AdvancedBackupSettings: - ResourceType: EC2 BackupOptions: WindowsVSS: disabled BackupPlanRule: - RuleName: "test-rule" TargetBackupVault: !Ref testvault ScheduleExpression: "cron(25 11 ? * * *)" Lifecycle: DeleteAfterDays: 2 CopyActions: - DestinationBackupVaultArn: arn:aws:backup:ap-northeast-3:xxxxxxxxxxxx:backup-vault:Default Lifecycle: DeleteAfterDays: 2 DependsOn: testvault testresource: Type: "AWS::Backup::BackupSelection" Properties: BackupSelection: SelectionName: "testresource" IamRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/service-role/AWSBackupDefaultServiceRole" ListOfTags: - ConditionType: "STRINGEQUALS" ConditionKey: "backup2" ConditionValue: "true" BackupPlanId: !Ref testplan DependsOn: testplan バックアッププラン バックアップルール 参考 https://aws.amazon.com/jp/premiumsupport/knowledge-center/aws-backup-cloudformation-template/ 基本はこの通りやればできます。公式 AWS Backupの薄い教科書 https://qiita.com/pioho07/items/68ccbc7b974b1466e7a6

前提情報 AWSアカウントID：333333333333 SNSトピック名：demotopic SNS設定 SNSトピック作成 SNSトピック作成手順は割愛します アクセスポリシーを以下のように修正 { "Version": "2008-10-17", "Id": "__default_policy_ID", "Statement": [ { "Sid": "__console_pub_0", "Effect": "Allow", "Principal": { "Service": "backup.amazonaws.com" }, "Action": "SNS:Publish", "Resource": "arn:aws:sns:ap-northeast-1:333333333333:demotopic" }, { "Sid": "__default_statement_ID", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "SNS:GetTopicAttributes", "SNS:SetTopicAttributes", "SNS:AddPermission", "SNS:RemovePermission", "SNS:DeleteTopic", "SNS:Subscribe", "SNS:ListSubscriptionsByTopic", "SNS:Publish", "SNS:Receive" ], "Resource": "arn:aws:sns:ap-northeast-1:333333333333:demotopic", "Condition": { "StringEquals": { "AWS:SourceOwner": "333333333333" } } } ] } サブスクリプション作成 サブスクリプション=>サブスクリプションの作成=>トピック選択、プロトコルはEメール(自身のEメールアドレスを設定) サブスクリプションフィルタに以下を設定。COMPLETED以外の正常ではないっぽいのだけ通知する { "State": [ { "anything-but": "COMPLETED" } ] } AWS Backupの通知設定(コマンドライン) 通知設定 $ aws backup put-backup-vault-notifications --endpoint-url https://backup.ap-northeast-1.amazonaws.com --backup-vault-name demo-vault --sns-topic-arn arn:aws:sns:ap-northeast-1:333333333333:demotopic --backup-vault-events BACKUP_JOB_COMPLETED 通知設定確認 $ aws backup get-backup-vault-notifications --backup-vault-name demo-vault { "BackupVaultName": "demo-vault", "BackupVaultArn": "arn:aws:backup:ap-northeast-1:333333333333:backup-vault:demo-vault", "SNSTopicArn": "arn:aws:sns:ap-northeast-1:333333333333:demotopic", "BackupVaultEvents": [ "BACKUP_JOB_COMPLETED" ] } テスト バックアップして中断する オンデマンドバックアップジョブ実行 すぐにジョブ停止 EC2のバックアップジョブ実行し、すぐ停止してみた 通知メール確認 An AWS Backup job was stopped. Resource ARN : arn:aws:ec2:ap-northeast-1:333333333333:volume/vol-05003f8ba0f210ab3. BackupJob ID : 6edb1940-4bfd-4688-8c40-4cfd4aec7d60 参考 https://aws.amazon.com/jp/premiumsupport/knowledge-center/aws-backup-failed-job-notification/ 基本はこれの通りやればできます。こっちが公式です https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/sns-notifications.html SNS を使用して AWS Backup イベントを追跡する公式ドキュメント https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/cloudwatch.html 他にもCWのメトリクスを監視しアラーム飛ばす通知も出来ます AWS Backupの薄い教科書 https://qiita.com/pioho07/items/68ccbc7b974b1466e7a6

僕の作成した環境 ELBーEC2（各AV内に１台ずつ）ーRDS EC2にはwordpressをインストール済み （それに必要なApatch,phpも） エラーの経緯 ①前回の作業でRDSを終了し、スナップショットを作成。 ②今回の作業を始める上で、前回作成したRDSのスナップショットの復元 ③ELBのエンドポイントでweb接続すると、データベース接続のエラーになった 考察 エラーに原因がデータベースの接続に問題があるということなので、スナップショットの復元した時に何か問題があったと仮定 原因 ・RDSスナップショットの復元の一つの設定ミスで、データベース接続のエラーが出てしまった。 解決法 ●データベース識別子を前回作成した名前と同じ名前にする必要があった。 あとがき 実は最初、間違った仮説を立てて、セキュリティグループの設定を変更したら、504 Timeoutエラーにはまった。 ELBのターゲットグループがunhealthyになってたので、セキュリティグループが原因だと、設定を戻したら解決。

はじめに boto3を利用したdynamoDBのscanでPaginatorを使用した場合に、filterExpressionを使用した際に、詰まったので、記事に残しておきます。 filterExpression FilterExpressionとは、条件を満たした項目だけが返されるような条件を指定します。他のすべての項目は破棄されます。 projectionExpression projectionExpressionとは、スキャン結果に必要な属性を指定します。 発見したバグ issueとしても上がっているのですが、boto3.dynamodb.conditions を利用した方法でfilterExpressionを使用すると、うまく使えない問題が発生します。 下記がその時のサンプル sample.py import boto3 from boto3.dynamodb.conditions import Key, Attr page_iterator = paginator.paginate( TableName=TABLE_NAME, IndexName=INDEX_NAME, FilterExpression=Key('X').eq(x) & Key('Y').lte(y) ) PaginatorでFilterExpressionを利用したい場合の書き方 簡単に書くと、ExpressionAttributeValuesを利用して、文字列で渡してあげるやり方にするとFilterExpressionを使用することができます。 sample2.py def scan_dynamo(): dynamoDBName = 'testdb' dateStr = 'xxx-xx-xx' filterExpression = 'time_stamp <= :searchDate' projectionExpression = 'id' try: cnt = 0 for page in dynamoPaginator.paginate( TableName=dynamoDBName, PaginationConfig=paginationConfig, ProjectionExpression=projectionExpression, FilterExpression=filterExpression, ExpressionAttributeValues={ ":searchDate": { "S": dateStr }, } ): print('Scan件数：{}'.format(cnt)) except Exception as e: print('DynamoDBのScanに失敗しました。TableName={0}, Error={1}'.format(dynamoDBName, e)) 参考

新しく検証環境を作りたいとき 本番環境を構築したいとき いらなくなった環境を消したいとき 現在の環境の設定を知りたいとき どうしますか？ 手順書見ながらAWSコンソール上で作業しますか？ 面倒くさくないですか？ 繰り返す可能性がある作業は Terraformでやっちゃいましょう。 Terraformとはなんぞや系は下記参照 https://www.lac.co.jp/lacwatch/service/20200903_002270.html EC2作成するサンプル Terraformをインストールする Macの場合 brew install terraform Amazon Linux2の場合 作業ディレクトリとsshキーを作る mkdir -p terraform/.ssh cd terraform ssh-keygen -t rsa -f .ssh/id_rsa_ec2 # パスフレーズは空で作成 他、ファイルを作っていきます touch {main.tf,terraform.tfvars} こんな構成になるようにしてください . ├── .ssh │   ├── id_rsa_ec2 │   └── id_rsa_ec2.pub ├── main.tf └── terraform.tfvars main.tf variable "private_key" {} variable "public_key" {} variable "vpc_security_group_ids" {} variable "subnet_id" {} // ここでプロバイダの設定 provider "aws" { profile = "default" region = "ap-northeast-1" } // ここでキーペアの設定 resource "aws_key_pair" "my-key-pair" { key_name = var.private_key public_key = file(var.public_key) } // ここでインスタンスの設定 // instance_count = XX で XX個 のインスタンスを一気に立てることもできる resource "aws_instance" "sample" { ami = "ami-0ddea5e0f69c193a4" // centos系のAMIを使っています instance_type = "t2.micro" monitoring = true tags = { Name = "sample" } associate_public_ip_address = true key_name = var.private_key vpc_security_group_ids = var.vpc_security_group_ids subnet_id = var.subnet_id } // ここでEIPの設定 resource "aws_eip" "sample-eip" { instance = aws_instance.sample.id vpc = true } // EIPを出力する設定 // EIPをターミナル上で取得できる // terraform output eip-for-sample output "eip-for-sample" { value = aws_eip.sample-eip.public_ip } terraform.tfvars private_key = ".ssh/id_rsa_ec2" public_key = ".ssh/id_rsa_ec2.pub" vpc_security_group_ids = ["sg-xxxxxxxxxx"] // 既存VPCのセキュリティグループID subnet_id = "subnet-xxxxxxxxxx" // 既存VPCのサブネットID デプロイ 基本的なコマンド # initialize terraform init # dry run terraform plan # deploy terraform apply # show terraform show # remove terraform destroy 今回は、まず init しましょう terraform init 次に、 plan で dry run をかけます。 これで、構文のチェックや、実際にデプロイできるかの確認を行います。 terraform plan 問題がなければ、 apply terraform apply SSH接続してみる キーペアも登録済みなので、もうSSHできる状態です。 下記コマンドで試してみてください ssh -i .ssh/id_rsa_ec2 centos@$(terraform output eip-for-sample | sed 's/"//g') SSHできたら 邪魔なリソースは必ず消しておきましょう。 EC2は放置してても課金対象です。 terraform destroy ほか 今回のサンプルコードでもある程度使えるかと思いますが、 VPCから作成したい とか Lambdaをデプロイしたい とか要件は様々だと思います。 自作して頑張ってもいいですが、 Terraform AWS modules という公式が出しているモジュール群を使用すれば、 頑張ることなく複雑な構成にも対応できます。

はじめに AWSLambdaのNodejsでAPIGateway経由でevent.bodyを取得しようとした際にundefinedになりハマったので、メモ exports.handler = async (event, context) => { // event.bodyがundefinedになる JSON.parse(event.body).hoge } 解決した方法 以下のように先にif文で確認してからだとundefinedにならない。 exports.handler = async (event, context) => { if (event.body) { JSON.parse(event.body).hoge } } 終わりに 上記の方法で問題は解決できたが、なぜundefinedになるのかがよくわからない。

はじめに こんにちは，ある企業の長期インターンシップに参加している大学４年生です. 今回インターンにて利用しているAWSのサービスの1つ「Fargate」について，安く運用したいと思ったこととその方法について書きたいと思います. そもそもFargateとは 公式ドキュメント： https://aws.amazon.com/jp/fargate/ コンテナ向けサーバーレスコンピューティングの一種であり，Dockerのイメージファイルを作るだけで簡単にデプロイできる便利なサービスです. 今回の課題 料金 ざっくり料金表（データ転送料+為替レートにより前後します） vcpu メモリ（GB） 料金（円/月） 0.25 0.5 1,236円 0.5 1.0 2,473円 1.0 2.0 4,947円 2.0 4.0 9,894円 （2021年6月12日現在の為替レートで月に732時間動作させた際の表です） 現在のインターン業務ではこのタスクをかなりの数同時稼動等をしているのでまともに動かすと， 100,000円 ~ /月を余裕に超えてしまうためこのコストそのものが課題になっています． 課題解決策 FargateSpot AWS Fargate Spotの発表 – Fargateとスポットインスタンスの統合 AWS Fargate キャパシティープロバイダー 大雑把に説明すると，価格が7割引になるFargateです． 実際に利用してみる まずFargateを利用するクラスターを作り，作成したクラスターを選択します． 右上にクラスターの更新というボタンがあるので押します． クラスターの更新を押すとキャパシティープロパイダー戦略という項目があるので追加し，FARGATE_SPOTを選択します． そして実行したいタスクをクラスター内にて利用することでFargateSpotを利用することが出来ます． 唯一の弱点 FargateSpotは連続稼働を保証しておらず，ある日突然タスクが終了することがあります... （今まで一度も終了したこと見たことないけど） Fargate Spotが空きキャパシティを確保できるかぎり、ユーザーは指定したタスクを起動することができます。 弱点をカバーする方法 タスク終了前にsignalが送られるのでタスク内で再起動処理を行う！ スポットの中断により Fargate Spot キャパシティーを使用するタスクが停止すると、 タスクが停止する前に 2 分間の警告が送信されます。 警告は、タスク状態変更イベントとして Amazon EventBridge に送信され、 実行中のタスクに SIGTERM シグナルが送信されます。 実際にタスク終了を検知するソースコードを下記に記載します. ソースコード import signal import sys import time import random import pprint # 何かしらの処理を行い最終的に出力する変数 # 配列・辞書等... response_data = [] def signal_receive_process(sig, frame): """SIGTERMシグナルを受け取った際に行う処理を書く""" print("SIGTERM!!") # 正常終了時の処理を行う task_finish_process() # タスクを終わらせる sys.exit(0) def task_finish_process(): """タスクが終了する際に行う処理を書く""" # 今回は単に表示させるだけ pprint.pprint(response_data[0:20]) def main(): """何かしらの処理（web・machine_running etc...）を書く""" # SIGTERMを検知する signal.signal(signal.SIGTERM, signal_receive_process) for idx in range(100): print(idx) # 何かしらの処理を行う append_data = idx * random.random() # データを格納する response_data.append(append_data) idx += 1 time.sleep(1) # 正常終了時の処理を行う task_finish_process() if __name__ == '__main__': main() 終わりに 今回，Fargateを安く利用する方法について主に書くことができました！ 今後も様々なことに書いていきたいと思います！

InsufficientInstanceCapacity エラーとは 対象の EC2 のインスタンスタイプを起動するためのキャパシティ (サーバー容量) を一時的に AWS 側で確保できない場合に発生するエラーです。インスタンス作成時や起動時に以下のようなメッセージが表示されます。 We currently do not have sufficient t3.micro capacity in the Availability Zone you requested (ap-northeast-1a). Our system will be working on provisioning additional capacity. You can currently get t3.micro capacity by not specifying an Availability Zone in your request or choosing ap-northeast-1c, ap-northeast-1d. 構築時にはエラー解消まで待てばよいのですが、運用時に発生するとクリティカルな影響が出るケースがあります。InsufficientInstanceCapacity に対する対策をいくつか記載します。 停止→起動ではなく、再起動を利用する InsufficientInstanceCapacity は新しいインスタンスを起動しようとしたり、停止したインスタンスを起動しようとする際に発生します。 参考: 稼働中のインスタンスの再起動操作 (RebootInstances API) を行った場合には、InsufficientInstanceCapacity は発生しません。EC2 の再起動操作は OS の再起動に相当します。OS の再起動が目的であれば EC2 の再起動操作でキャパシティ不足を回避できます。 EC2 のリタイアメント通知等で稼働ホストの変更が必要な場合は、再起動では対応できません。必ず停止→起動の手順を踏む必要があります。キャパシティ不足の発生を避けたい場合にはキャパシティ予約の利用を検討ください。 キャパシティ予約を利用する オンデマンドキャパシティ予約 オンデマンドキャパシティー予約 を使用すると、特定のアベイラビリティーゾーンで任意の時間だけ、EC2 インスタンスのキャパシティを予約できます。予約が作成されると EC2 の起動有無に関わらず確保したコンピューティング料金分の課金が開始されますが、その間は対象のインスタンスタイプの起動が保証されます。メンテナンス等の対応後はキャパシティーの予約をキャンセルすれば料金は発生しなくなります。 オンデマンドキャパシティ予約を作成するには、インスタンスタイプ、OS プラットフォーム、AZ、テナンシー、数量を指定する必要があります。 オンデマンドキャパシティ予約のオプションとして Instance eligibility (インスタンスの利用資格) があり、以下の2種類から選択できます。 open (一致する詳細を持つ任意のインスタンス) 一致する属性を持つインスタンスに対し、キャパシティの予約が自動的に適用されます。すでに稼働中のインスタンスにも自動で適用されますが、インスタンス ID の指定などはできません。特定の AZ に m5.large が 4 台あったとして 2 台 をオンデマンドキャパシティ予約したとしても、どのインスタンスに適用されるかは予測できません。 targeted (この予約を指定するインスタンスのみを受け入れます) targated で作成されたキャパシティー予約は EC2 作成時または起動時に明示的に使用する必要があります。自動適用はされません。起動中のインスタンスに適用するには一度停止を行い、インスタンスの設定でキャパシティ予約の設定を変更して使用を明示する必要があります。 目的のインスタンスにキャパシティ予約が適用されているか確認するには EC2 ダッシュボードの詳細から確認することができます。 オンデマンドキャパシティ予約時にもインスタンスの供給状況によっては InsufficientInstanceCapacity が発生する可能性があります。目的の作業直前で実施する場合、確保できない可能性もありますのでご注意ください。 その他の詳細はドキュメントもご参照ください。 リザーブドインスタンスによるキャパシティ予約 AZ をスコープとしたリザーブドインスタンスを購入している場合には購入台数分のキャパシティが予約されています。リージョンをスコープとしたリザーブドインスタンスまたは Savings Plan を使用している場合はキャパシティ予約は適用されませんので、必要に応じてオンデマンドキャパシティ予約をご使用ください。 参考: オンデマンドキャパシティ予約、リザーブドインスタンス、Savings Plans の比較は以下のとおりです。 オンデマンドキャパシティ予約 ゾーン リザーブドインスタンス リージョナルリザーブドインスタンス Savings Plans コミットメント 不要、必要に応じて作成・キャンセル可能 1年または3年のコミットメントが必要 1年または3年のコミットメントが必要 1年または3年のコミットメントが必要 キャパシティ予約 あり あり なし なし 請求割引 なし あり あり あり その他の対策 その他一時的な回避策をあげます。AZ やインスタンスタイプを変更した場合、システムによっては後日もとの状態に戻さなければならないケースもあるかと思います。 インスタンスタイプの変更 InsufficientInstanceCapacity は特定の AZ のインスタンスタイプにおける供給状況により発生するため、インスタンスタイプを変更することで回避できる可能性があります。 e.g., t3.medium → t3.large, m5.large → c5.large など 別のアベイラビリティゾーンで起動 InsufficientInstanceCapacity は特定の AZ のインスタンスタイプにおける供給状況により発生するため、エラーが発生した AZ とは異なる AZ を指定することで回避できる可能性があります。EC2 インスタンスは AZ の移動ができないため、バックアップや AMI から新しいインスタンスを作成する必要があります。プライベート IP アドレスも変更されます。 数分待ってからリトライ キャパシティは頻繁に変動する可能性があるため、何度かリトライすることで起動に成功する場合があります。許容できるダウンタイムが短い場合にはリスクがあるため、キャパシティ予約を検討してください。 フリート機能の活用 アプリケーションとして Auto Scaling を使用している、 AZ やインスタンスタイプの違いを許容できるといった特性があれば、各サービスにおけるフリート機能を活用することで InsufficientInstanceCapacity に対し耐久性を持たせることが可能です。これらの機能を活用すると複数のインスタンスタイプを事前に指定できるため、ある AZ のインスタンスタイプで容量不足が発生した場合でも別のインスタンスタイプで起動させることができます。 EC2 Fleet EC2 フリートは、インスタンスのフリート (グループ) を起動するための設定情報です。複数のインスタンスタイプ、購入オプション (オンデマンド、スポット、リザーブド) を指定し、 指定した容量のコンピューティングリソースを確保することができます。EC2 Fleet は API または AWS CLI からのみ利用できます。 参考: Auto Scaling Geroup 2018 年のアップデートにより、EC2 Fleet の機能が EC2 Auto Scaling にも拡張されました。1つの Auto Scaling Group 内で、複数のインスタンスタイプや購入オプション (オンデマンド、スポット、リザーブド) を組み合わせて利用できるようになりました。 参考: インスタンスフリート (Amazon EMR) Amazon EMR でクラスターを作成する際にインスタンスフリートを選択できます。マスターノード、コアノード、およびタスクノードの構成オプションとして複数のインスタンスタイプと購入オプション (オンデマンド、スポット) を指定することができます。 参考: 以上です。 参考になれば幸いです。

Gravio Hubで音声再生ができるようになったのでいろいろ試してみたくなった。 以前、客先でやったことのある通称「お茶出しくん」の音声版を作ってみる。「お茶出しくん」はお客様対応中にボタンを押すとお茶やコーヒーをお願いできるもの。以前はLINEで通知してみたが、スピーカーで喋ってくれるとLINE見てなかったーってことはなくなる。まぁ、人がいなければやはり意味はないのだが、その場合はLINEとハイブリッドで。 使用環境 Gravio HubKit v4.3.0-6722 Gravio Studio v4.3.4162.0 Gravio ワイヤレススイッチ Gravio Hub Bluetoothスピーカー Amazon Polly 事前準備 「Gravio HubにBluetoothスピーカーをペアリングする」 を参考にGravio Hubでスピーカーをペアリングしておく AWSにアカウントを取得し、Amazon Pollyを使えるアクセスキー、シークレットキーを取得しておく 手順 Gravioワイヤレススイッチを設定 まずは、呼び出し用のボタンをペアリングして、レイヤーに紐付けます。 エリア名は今回利用するのでちゃんとわかりやすい部屋の名前で。今回は「会議室」としておきます。 基本プロパティセットを作成 AWSのアクセス情報を基本プロパティセットに設定しておく。せっかく取得したので、今後も再利用できるように。 アクションを作成 アクションを作成します。 コンポーネントはAWSPollySpeechだけですね。 プロパティも簡単。基本プロパティセットには先ほど作成したものを選択し、音声は今回日本語を話すので、「Mizuki」さんか「Takumi」さんを選びます。 あとは話す内容です。 cp.Text cp.Text = tv.AreaName + "にコーヒーをお願いします" tv.AreaName でボタンの置いてあるエリアの名称をくっつけてます。これで、いくつかの会議室があった場合でも、どこに持っていけばいいか簡単にわかりますね。 トリガーを作成 最後にトリガーを作成して、ボタンとアクションを紐付けます。 エリアとレイヤーを選び、ボタンのイベントは「Single press」を選んでおきます。 アクションは先ほど作成した「CoffeePlease」を選びます。 試してみる ボタンを押すとスピーカーから「会議室にコーヒーをお願いします」と流れます。 これ、スピーカーもボタンをワイヤレスなので、Gravio Hubと離れた位置に置くことができます。これって結構大切です。設置の自由度が上がれば、利用用途も格段に広がりますね！ 参考 Gravio HubにBluetoothスピーカーをペアリングする Gravio AWS Polly Speechコンポーネント Amazon Polly

資料 人事システム「COMPANY」のバッチ処理の裏(側) の話 - Qiita バッチサーバーを ”Fargate化” しました - Qiita アジェンダ: バッチサーバーFargate化総括 概要 稼働状況 評価 今後の課題 概要 動機 バッチサーバーにおける以下を達成する。 よりシンプルな冗長構成 コスト削減 従来構成 動機に伴う主題 AWS ECS Fargate を用い、コンテナ起動でバッチごと必要時のみのバッチサーバーサービス起動を行い、バッチ実行を実現する。 動機に伴う解決策 現プロダクトの「バッチ実行」の以下処理フロー 実行命令 キュー指定、バッチサーバー選択 処理実行 2以降をFargateに置き換える。 フロー詳細: 人事システム「COMPANY」のバッチ処理の裏(側) の話 - Qiita 稼働状況 ​バッチサーバーを ”Fargate化” しました - Qiita 設定を切り替えることにより使用可能な状態（かつ既存動作に影響は出ない状態）を2020年末までに達成。 評価 評価点・反省点 2021年1月より稼働検証を行った。以下が考えられる。 　　　　　 メリット デメリット 対ユーザー 可用性の向上 - EC2リソースに制限されないバッチ実行 (並列に実行できるバッチの増加・キューの制限の解消)。 - 実行時間の増加による業務実行への影響。 対製品全体 コスト削減。AWS移行によって独自キュー管理をなくせる (最適化された構成・保守工数の削減) - 対インフラ 可用性の向上、クラウドコスト削減 トラブルシュート時の運用の変化。 対ドメイン 可用性の向上 - 問い合わせ時のログ取得の簡易化が必要。 - トラブルシュート時の運用の変化。 - 実行時間の増加による問い合わせの懸念。 今後の課題 問題点 現段階では既存の冗長化機能を利用した現状維持 or 制約を受け入れてFargate版を使う、の2択である。以下比較。 既存のバッチ処理 構成: AZ-aにインスタンス1台を作成。冗長性は確保できない。 冗長性: 無し。 コスト: バッチを実行しない時間でもインスタンス起動料金がかかる。 時間: テストバッチで10~20秒ほど。 メリット: 実行時間が他2つと比較して早い。 デメリット: インスタンス管理が必要。冗長性を確保できないため、障害時はインスタンスの復旧までダウンタイムがかかる。 ECS Fargate TASK起動 構成: インスタンスは保持しない。都度TASKを作成、コンテナ起動。冗長性が確保できる(必要に応じてフルマネージドでコンテナが起動可能) 冗長性: 担保可能。 コスト: 実行時間分のみの課金→最適なコストの実現。 時間: テストバッチで1分30秒ほど。TASK作成からコンテナ起動までが50秒ほどかかる。 メリット: インスタンス管理が不要。コストの最適化。冗長性を確保でき、バッチ処理のだダウンタイムをなくせる。 デメリット: コンテナ起動時間が遅く、短いバッチを何度も実行する場合、オーバーヘッドが無視できない。 ECS EC2 構成: ECSインスタンスを作成・保持。ECSインスタンスを複数保持することで冗長性が確保できる。 冗長性: 担保可能。 コスト: バッチを実行しない時間でもインスタンス起動料金がかかる。本番環境ではコスト増になる。 時間: テストバッチで1分ほど。TASK作成からコンテナ起動までが15秒ほどかかる。Fargateよりは30~40秒起動が早い。 制約: インスタンスタイプによって同時に起動できるTASKに制限がある。 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/container-instance-eni.html メリット: 冗長性を確保でき、バッチ処理のダウンタイムをなくせる。Fargateよりは早い起動時間であり、許容範囲に収まる可能性。 デメリット: インスタンス管理が必要。同時に起動できるバッチに制限が生まれる。制限を拡張する場合、インスタンスコストが増えるので、コスト増につながる。 改善要望・ほか参考資料 AWS Fargateを本番運用した所感 - コネヒト開発者ブログ タスクの起動速度がEC2バックエンドと比べるとやはり遅い Fargateにするとホストが固定されないため、Docker Pull時のレイヤキャッシュが効かなくなります。それが理由でEC2バックエンド時代と比べるとECSサービス更新からコンテナが立ち上がるまでの時間が約1.5〜2分程遅くなりました。その分デプロイ速度が遅くなってしまいます。 これはDockerイメージのサイズも大きく影響するので一概には言えないですが、アーキテクチャ上仕方ないとは思いつつ、AWSの今後の進化に期待したい部分だと思っています。Cron的な起動時間が厳格に求められるスケジュールバッチのバックエンドには、FargateでなくEC2バックエンドを使うのが今のところは正解かなと個人的には思っています。 Amazon ECS Fargate/EC2 起動タイプでの理論的なコスト最適化手法 | Amazon Web Services ブログ AWS Fargate のイメージサイズ毎の起動時間の違い - Qiita AWSでバッチ処理を実装する際の選択肢とサービス比較 別案 「バッチ処理」の再整理。10秒20秒で終了する処理をバッチ形式で実行している背景の整理など。 参考: バッチ処理について考える - Qiita 次フェーズ・タスクの再開条件 Fargate でのバッチ実行時間が今よりも30秒ほど短くなっていること。あるいは、ボトルネックになっている短いバッチ実行をアプリケーションサーバーなどに移設すること。 以上公開可能な範囲でまとめたもの。参考になればさいわいです。

トランザクションってなんだっけ？ よくもやもやするので整理をしておく。 データベースをある一貫した状態から別の一貫した状態へと変更する一連の処理を1つの束として見るという手法。 データベースを扱う上で 同時アクセスした場合の処理(整合性の問題) 処理中のエラーやデータベース依存ではない障害に対しての処理の中断と復元、及び保護の問題 という以上の2点の問題はつきものであるということは私のような初心者でもわかる。 なので、ある程度語弊を覚悟でざっくり言ってしまうとこのトランザクションという仕組みがあることで 同時アクセスに対してはAとBどちらの束を優先させるかを決定して一貫性と整合性を保つ 一連の処理を束とみているからこそ、処理のどこかでエラーや障害が起きた場合はその処理は実行されずロールバックされることで元のデータは保護される という対策を取れることになる。 ただし、これは反面処理に遅延をかけていることにもなるので逆にトランザクションを保証しないことで高速処理を担保するという仕組みのDB程度も存在する。 ACID ACID(Atomicity Consistency Isolation Durability)は信頼性のあるトランザクションシステムの持つべき性質の頭文字をあわせたもの。 Atomicity(原子性)……トランザクションの状態は「処理がすべて実行される」か「処理が一つも実行されない」のどちらかにしかならないという性質 Consistency(整合性)……トランザクションの前後でデータの整合性が保たれ、矛盾のない状態が継続されるという性質 Isolation(独立性)……トランザクション実行中の処理過程が外部から隠蔽され、他の処理などに影響を与えない性質 Durability(耐久性)……トランザクションが完了したら、その結果は記録され、クラッシュしても失われることがないという性質 整合性の話 整合性はレベルがあって色々と良し悪しがある。 例えば結果整合性であれば 変更中のデータが完了していない状態でも、当該データの変更前の状態は確認できる ただし、上記のケースではデータの整合性という意味では弱い けれどもDBの処理の負荷は整合性を強くした場合よりは低い ここから整合性を強くすると以下のケースが考えられる。 変更中のデータに対して、完了するまでは参照はできない。DBの処理負荷も高くなる。 ただし、データの整合性は高くなる データベースのタイプについて なんとなくは知っているけれどおさらいしておく。 リレーショナルDB その名の通りデータ間の関係性を定義していくことでデータを構造化して取り扱うDBシステム 各列(カラム)のデータが集まった1行のレコードを集めたテーブルを構成し、そのテーブル間で関係性(リレーション)を設計していく SQLで操作する 行指向(データをカラムで表現してその集合を1行として取り扱う) 会計データ、顧客データといったものに向いてる ORACLE、MySQL、PostgreSQL、SQL Server、RDS等が該当 NoSQL リレーショナルデータ構造を持たず、SQLを利用しない(SQLに似たクエリ処理を使う感じ) 大きな特徴として非構造化(テキスト・動画・音声・画像)・半構造化(XML・JSON・文書)という2パターンでデータを格納する KVSデータ(Key(ID)に対してValue(データ)のみというデータ方式)、非構造化データ、半構造化データを扱う場合に利用する。 ビッグデータ解析に用いることができる DWH(データウェアハウス) データの抽出・集約に特化したBIデータ(ビジネスインテリジェンスデータ、ビジネスの意思決定に関わるデータの総称らしい)分析用のデータベース 読み込むデータ構造を予め設計・加工してから利用するデータの蓄積を開始する レスポンス重視でデータ抽出・集計は早いが、更新・トランザクションは遅い データはパーティショニングされ、複数のディスクから読み込まれる RDBの一種であるが、分析に特化するために敢えて列指向でデータが格納している 構造化データを利用した経営分析向けのデータベースである 会計データなどの業務系の構造化データを分析用に加工し、BIとして利用する 利用例としてはKPI(Key Performance Indicator、重要業績評価指標)測定、競合分析、アクセス分析など ORACLE Exadata、VERTICA、TERADATA、Greenplum、Redshiftなどが該当 分散型DB/データレイク ビッグデータ、IoTデータの蓄積と高速処理を可能にするDB及びストレージの組み合わせである データ抽出に特化していて、ビッグデータの高速処理を必要とする場合に適している 分散してデータを保存している SQLライクな操作感 INSERT、DELETE、UPDATEはない トランザクションもない データ書き込みは一括ロードまたは全件削除のみ Impala、HIVE、prestoなどのオンプレにHDFSというソフトウェアの組み合わせやS3などがこれに該当する 全検索型エンジンと分散DBの利用 分散型DBと連携することで検索データベースを構築して、データ全検索処理を可能にすることが目的 検索条件との関係性、関連性が高いデータを抽出して返してくれる Elastic Searchは全文検索用のライブラリでApache Luceneを利用したデータストア 分析の柔軟性や速度が高く、分析・蓄積・可視化環境を容易に構築することができる 半構造化データ、高可用が必要な全検索エンジン、サイト内データ検索、リアルタイム検索要件・検索行動の可視化(ex. デバイスの登録状況や配信状況)に適している Elastic Search、kibana、Elasticsearch Serviceがこれに該当する 分散OLTP RDBの一種でオンライントランザクション処理を分散化する次世代DB RDBであるのにグローバルに分散されたDBであるのが大きな特徴 強整合性を採用している リレーショナルデータベースの構造と非リレーショナルデータベースの分散スケーラビリティを兼ね備える 高い可用性、高性能なトランザクションと強整合性を実現している 大規模な業務データ処理 Amazon Auroraがこれに該当する NoSQLのタイプ KVS(キーバリューストア) Keyに対してValueを入れる 高速なパフォーマンスと分散型拡張に優れている データ読み込みが高速 シンプルなオペレーションを高速実施したい場合に適している 結果整合性を採用 分散向けのデータモデル及びクエリを採用 トランザクション、集計、JOIN等は利用できない 大規模WEBサイトのバックエンドデータ(ex. ユーザーセッション、ユーザー属性、事前計算データのキャッシュ)、メッセージングシステムのデータ、大規模書き込みが必要となるIOTセンサーで用いるデータ等に利用する redis、riakというオンプレDBやElastiCache、DynamoDBがこれに該当する WCS(ワイドカラムストア) 列指向とも呼ばれ、キーを利用するがデータは列(Column)で管理する 非構造データを大規模に格納することを目的としている 行ごとに任意の名前のカラムを無数に格納できる KVSの亜種になるので同じく分散させて、シンプルなオペレーションを高速実施したい場合に適している データ取得の際にデータ結合しなくて済むように、可能な限り多くのデータを同じ行に保持する 結果整合性を採用 キースペース、カラムファミリ、ロウ(スーパーカラム)、カラムの入れ子構造 SQLライクな操作感 データ操作は挿入、削除、参照のみ データの更新は挿入による上書きのみ FacebookやTwitterなどのソーシャルデータの位置情報データストレージやリアルタイム分析、データマイニング処理に適している cassndra Apache HBASS、DynamoDBがこれに該当する DDB(ドキュメントデータベース) Keyに対してValueではなく、直接JSONやXMLを入れる 複雑なデータ構造を扱うアプリで高い生産性と柔軟性を持たせることができる 様々なデータ構造のドキュメントを混在して保存することができる JSON/XMLをデータモデルとして利用する 小規模データの同期集計処理が可能であるが、バッチ処理には不向き SQLな操作感、KVSと比べるとクエリも豊富 シャーディングによるデータベース分散化を実現 半構造化データ、大規模WEBのログ保管、オンラインゲームデータ、カタログ管理に適している monogoDB、MarkLogic、CouchDB relax、Couchbase、Amazon DocumentDBがこれに該当する インメモリデータグリッド KVSをインメモリで行う仕組みのDB 大量のデータを多数のサーバーのメモリ上で分散して管理する技術 ミリ秒単位の高速の応答処理が可能 データはメモリに置かれ、多数のサーバーで分散して管理される ミリ秒以下の応答時間を必要とする金融取引処理データなどに適している Apache GEODE、Apache Ignite、ORALCE Coherence、hazelcast、InfinisonやRedis ElactiCache、Memcahes ElastiCacheなどがこれに該当する GDB(グラフデータベース) グラフ理論に基づきデータ同士の関係をグラフで相互に結びつけた要素で構成されるDB マインドマップのようにデータの関連性をグラフ表示するようなデータ構造を形成する 高速横断検索が可能である グラフ演算に特化していて、データ間のつながり方を検索・可視化したい場合に利用する グラフデータ構造を取るため、RDB以上にスケールアウトができない レコード数が増えると、検索にかかる時間と難易度が増大する ACID特性が担保されていて、オブジェクト間の関連付けを簡単に表現できる 最短経路探索、金融取引の詐欺検出、ソーシャルネットワークによるリレーション計算に適している neo4j、Amazon Neptuneがこれに該当する AWSにおけるデータベース関連のサービスの立ち位置 Well-Architected FrameWorkでいうなら 信頼性 パフォーマンス効率 ベストプラクティスで言うなら スケーラビリティの確保 キャッシュの利用 増大するデータへの対応 最適なデータベースの選択 サーバーではなくサービス 使い捨てリソースの利用 がAWSにおけるデータベース関連のサービスの主な立ち位置となる。 最適なデータベースの選択 データの特徴に応じて利用するDBを選択するというのがベストプラクティスであるが、単なるアプリケーションであればMySQLやMarinaDB、PostgreSQL等で大体事が足り、モバイルアプリでFireStoreのようなNoSQLを選択する場合があるだろう……という話でおしまいになる。 しかし、現在はビッグデータを活用することが当たり前になりだからこそAWSやGCPを利用する……なんてことにも繋がるわけである。 つまり、最適なDBの選択というのは旧来のそれは 既存の構造化データの保存・管理 上記のアーカイブデータの保存・管理 という観点加えて、それを分析して業務に活かすという目的のために最適な選択をするという意味になり、新たなに IoTデータから得られた音声・動画等々の非構造化かつ膨大なビッグデータの保存・管理・分析 同じく半構造化データの保存・管理・分析 という目的のために最適なDBを選択するという意味を持つということになる。 当然、この分野は特にリアルタイム性(ストリームデータを扱う)、AI・人工知能構築というところにも大きく関わる。 DBの分類 分散型(複数のDBを並列で繋げる形でスケーラビリティを実現するタイプ)か拡張型(1つのDBをスケーラビリティするタイプ)か 業務用アプリケーション向けか分析用途向けか 以上の2軸に分かれる。 個別に列挙すると 分散型かつ業務・分析中道……KVS、DDB、Elastic Search 分散型かつオペレーション向け(業務用向け)……インメモリデータグリッド、分散OLTP(OnLine Transaction Processing、トランザクション処理を端末からの要求に対して即座に実行する方式のこと) 分散型かつ分析向け……データレイク(Hadoop HDFS等) 拡張型かつオペレーション向け……RDB(RDBにおけるOLTPも含む)、グラフDB 拡張型かつ分析向け……データウェアハウス DynamoDB 完全マネージド型のNoSQLデータベースサービスである。 ハイスケーラブルで無制限に性能を拡張できる 負荷が高くなっても応答速度が低下しない低レイテンシー 高可用性(SPOF(Single Point Of Failure、つまり単一障害点のこと)なしでデータは3箇所のAZに保存される) マネージド型のためメンテナンスフリーで利用できる(CloudWatchで運用を監視・分析する) プロビジョンドスループットを採用し、テーブルごとにReadとWriteに必要なスループットキャパシティを割り当てることができる → つまり、テーブルごとに読み出しに強くするのか書き込みに強くするのか設定できる ストレージの容量制限がないのでデータ容量の増加に応じたディスクやノードの増設が一切不要 ワイドカラム型を採用、つまりデータ操作を簡易にする代わりに複雑なクエリやオーダーには対応できない 結果整合性を採用、ただしReadに対しては整合性を強くすることができる(GetItem、Query、Scanのアクションに対して設定できる) パーティショニングよる分散並列処理を実施(ex. 1つのテーブルを3つにパーティションする) できることは Key-ValueのCRUD操作 簡易なクエリ、オーダー 数万人以上が同時にアクセスして、それに対して処理を実行しなければならないようなアプリケーションデータ処理 逆に不向きなことは JOIN・TRANSACTION・COMMIT・ROLLBACK処理(そもそもできない) 詳細なクエリやオーダー、つまり複雑なデータ検索及びデータ結合は不可 大量のデータの読み書き(コストが膨大にかかってしまうので) となる。 ユースケース 大規模データを扱う場合は結果的にRDSよりコストパフォーマンスがよくなることがあることに注意。 トランザクションで発生しうるデータベース処理を検討または監視・分析することで採用、あるいはRDS等からの移行を検証する。 例えば銀行の振り込み処理に関してはTRANSACTION・COMMITMENT・ROLLBACKいずれも必要不可欠なのでRDSを採用……となる。 逆にいうとそれらのいずれも必要ではなく、大規模・大容量のデータを高速で処理することが想定されるならDynamoDBを検討する……という話。 基本的にはサーバレス等を鑑みてDynamoDB程度ファーストで検討し、適さない場合は順次RDS等で代替えを行う方向でアーキテクチャを検討する。 ビッグデータ 大量のデータを収集・蓄積・分析するためのデータベースとして活用 Hadoopと連携することでビックデータ処理も可能になる アプリケーション 大規模サービスでデータ高速処理が必要なアプリケーション向けに活用 多数のユーザーが一度にアクセスするようなアプリケーションのデータ処理などに利用 ユーザー行動に対してのデータ管理 ユーザー情報やゲーム、広告などのユーザー行動データ向けDB ユーザーIDごとに複数の行動履歴を管理したいときに利用 バックエンドデータ処理 主にモバイルアプリケーションに対しての バックエンド バッチ処理のロック管理 フラッシュマーケティング ストレージのインデックス に利用。 DynamoDBのテーブル設計 テーブル・項目・属性で構成される。 テーブル……データのコレクションを指す、まあRDBにおけるテーブルと役割は変わらない 項目……属性の集合、つまりRDBにおける行のような役割。ただし、項目間は一意に識別できないといけない 属性……項目を構成する要素、つまりDynamoDBにおける最小のデータ単位 ex. テーブル(人事管理部) 項目(Personal1、Personal2……n) 属性(姓名、性別……etc) なお、属性に入るデータ型は不揃いであっても構わない。 DynamoDBにおけるインデックス PK及びLSI、GSIと呼ばれるものをインデックスとする。 1テーブルにつき1つ、データを一意に特定するためのハッシュキーやレンジキー(これらはPKとなる)を宣言してインデックスとする。これは暗黙的なキーと言われる LSI(Local Secondary Index)はプライマリキーのタイプがハッシュキーやレンジキーの場合の追加レンジキーの役割となるインデックス LSIは1テーブルに5つ作成可能で、テーブル作成時にのみ作成できる明示的なキーとなる LSIはレンジキー(複合キー)によって整理されている項目に対して設定でき、さらに別の規則でのインデックスを可能にする GSI(Global Secondary Index)は別のハッシュキーとして設定できる全データに対してグローバルに付与されるキー GSIは1テーブルにつき5つ作成可能で、LSIとは違いテーブル作成後に追加で作成する明示的なキーとなる GSIはハッシュキーの属性の代わりとなり、ハッシュキーテーブル及び複合キーテーブルどちらにでも設定可能 GSIを使ってハッシュキーをまたいで自由に検索ができるようにする LSIやGSIはスループットやストレージ容量に負担をかけ、書き込みも増大するために多様はできない DynamoDBにおけるPK ハッシュキー KVSにおけるキーに相当するデータを一意に特定するためのIDなどのこと テーブル作成時に属性を1つ選んでハッシュキーとする ハッシュキーは単独での重複は許されていない レンジキー ハッシュキーにレンジを加えたものをレンジキーまたは複合キーと呼ぶ テーブル作成時に2つの属性を選び、1つをハッシュキーとして、もう1つをレンジキーと呼ばれるキーとして宣言する 2つの値の組み合わせによって、1つの項目を特定する 複合キーは単独であれば重複が許される DynamoDBにおけるテーブル操作 GetItem……ハッシュキーをキーにして一定の項目を取得する PutItem……項目を書き込む Update……項目を更新する Delete……項目を削除する Query……ハッシュキー及びレンジキー(つまりPK)にマッチする項目を取得する(1MBまで) Scan……テーブルを全件検索する(1MBまで) BatchGetitem……複数のPKに対してマッチする項目を取得する DynamoDB Streams DynamoDBテーブルに保存された項目の追加・変更・削除の発生時にその履歴をキャプチャできる機能。 過去24時間以内のデータ変更の履歴を保存し、24時間を経過すると消去される データ容量はマネージド型で自動的に管理される 操作が実施された順番に応じてデータがシリアライズされる 特定のハッシュキーに基づいた変更は正しい順番で保存されるが、ハッシュキーが異なる場合は受信した順番が前後される可能性がある DynamoDBのクロスリージョンレプリケーションにおいて、ストリームによるキャプションをトリガーとしてそれを実施できる データ更新に応じた通知処理などのアプリケーション処理の実行のトリガーとして使える 例えばこの機能でキャプチャした履歴を元にLambda関数によって DynamoDBの別テーブルを自動更新 S3にログを保存 SNS等でプッシュ通知 などの処理を自動化して行うことができる。 DynamoDB Accelerator(DAX) DAXはDynamoDBにインメモリキャッシュ型の機能を付加することができる機能。 DynamoDBに対してのアクセスに対し、キャッシュがあればそちらを優先させる。 インメモリキャッシュとして1桁台のミリ秒単位からマイクロ秒単位まで、結果整合性のある読み込みワークロードの応答時間を短縮する マルチAZでDAXクラスターを用いると、1秒間に数百万件のリクエストを処理できる DAXはDynamoDBを使用するAPIと互換性を持つマネージド型サービスであり、運用上そしてアプリケーションの複雑性を減少させて容易に導入可能である 読み取りの多いワークロードや急激に増大するワークロードに対して、スループットを強化したり、読み取りキャパシティユニットを必要以上にプロビジョニングしないように設計することで運用コストの節約ができる グローバルテーブル DynamoDBはリージョン間で同期されるマルチマスターテーブルを作成することができる。 同期されるマルチマスターテーブルつまり、クロスリージョンレプリケーションを取るのでその性質上DynamoDB Streamの設定が必須となる。 (レプリケーション先に変更があったことと、その履歴を通知しないとレプリケートできないため) DynamoDBの性能のまま、世界中で複数のリージョンにエンドポイントを持つことができる 読み書きのキャパシティに加えて、クロスリージョンレプリケーションのデータ転送料金に課金される 本来オプションで実施できた強い整合性は不可 DynamoDB Streamでキャプチャされたデータの変更履歴を元にレプリケーションを行う オンデマンドバックアップ パフォーマンスに影響なく、数百TBでバックアップができる。 任意のタイミングで利用可能な長期間データ保存用バックアップ 従来はデータパイプラインを利用して取得したバックアップを容易に実施できるようになった Read/Writeキャパシティオンデマンド キャパシティ設定不要でリクエストに応じた課金設定を選択できる。 トラフィック量の予測が困難な場合にリクエストの実績数に応じて課金できる オンデマンドRead/Write処理に自動スケーリングを実施できる プロビジョンドキャパシティ設定への変更は無制限 オンデマンドへの変更は1日1回まで Amazon Aurora RDBではあるが、分散型のDBであるAmazon独自の仕様のDB。 高い並列処理によるストレージアクセスでクエリを高速で処理することが可能であり、大量の読み書きを同時に扱うことができるのが特徴。 分散型リレーショナルDBという新しい規格 NoSQL型の分散高速処理とRDBとしてのデータ操作性の両立を目指す MySQL相当の商用DBと比べて価格は1/10で性能は2.5~5倍(公称) 高い並列処理性能によって大量の読み書きをするのに適したDB DBの集約及びスループットの向上が期待できる 高性能はあくまでも公称なので、有効となるべき領域を判断して使うことが肝要 MySQL5.6及びPostgreSQLと互換性がある MySQL5.6及びPostgreSQLのSnapshotからマイグレーションすることでAuroraへと移行することもできる EFSをEC2インスタンスから操作する際には専用のクライアントソフトウェアを利用する また、フルマネージド型であり耐障害性と自己回復性を兼ね備えているのも特徴である。 3つのAZに2つのコピー、つまり計6つのコピーを設置可能 過去のデータがそのままS3へと継続的にバックアップされる リストアも差分適用がなく高速である どのタイミングでも安定したリストア時間を実現 99.99%の高可用性・高耐久性 10GBから最大64TBを提供するSSDデータプレーンを利用してシームレスに拡張ができる Auto-Scalingなどのクラウド独自のスケーラブルが可能 最大15のリードレプリカを利用した高速読み込みが可能 マスターDB自体をリードレプリカのように複数構築することも可能(Write機能のスケーラブル可) リードレプリカ、クロスリージョンリードレプリカの他にAuroraのDBクラスタ構成自体をクローンを作成することもできる DBクラスタクローンの機能によって、同一の環境を容易に複製することができる 以下のように大規模なクエリ処理が発生するRDB環境(特に中規模以上)などを扱っている、または扱う予定の場合はAuroraの採用・移行を検討する。 書き込み量が多く、トランザクション量が多い クエリ並行度が高い、データサイズが大きい コネクション数やテーブル数が多いデータベース処理である 上記のようなユースケースに合わせて、スケーラビリティの高さやデータ容量を無制限に拡張できるメリットを享受できる場合 レプリケーションなどの性能の高さを活かせる場合 Auroraの構成 基本的には1つのDBインスタンスと1つの仮想クラスタボリュームで構成される。 仮想クラスタボリュームは前述の通りAZあたり2つ、合計6つのコピーが作成できるがこれらを単一のボリュームとしてみなしたものが仮想クラスタボリュームである。 次にDBクラスタという構成を見てみる。 AuroraはマスターとそのリードレプリカをまとめてDBクラスタとして構成することができる。 この場合、例えばマルチAZでELBを使って分散処理をするようなVPC構成をしている場合、書き込み処理はエンドポイントからWriterが指定されることになる。 つまり、マスターがあるAZに処理が振られる。 同じように読み込み処理はエンドポイントからReaderが指定される。 この場合の処理フローは マスターがあるAZのEC2から読込処理のアクションが行われる エンドポイントへパスされる エンドポイントが適切なReader(つまりリードレプリカ)へ処理をパスする ということになる。 さらにマスターに障害が起きた場合はエンドポイントが自動的にReaderのいずれかへとフェイルオーバーする仕組みになる。 Auroraサーバレス 予測困難なアプリケーションワークロードに対応したAuroraのオンデマンド自動スケーリング構成。 アプリケーションのニーズに応じて自動的に起動やシャットダウン、スケールアップやスケールダウンを行う。 AuroraグローバルDB より高性能なリードレプリカを作成することもできる。 ログ転送ではなく、ストレージレベルのレプリケーション機能を利用してのレプリケーション より低レイテンシーなレプリケーションを行える EFS EFSはEBS(ブロックストレージ)・S3(オブジェクトストレージ)と並ぶAWSのストレージサービスでNASに似たファイルストレージサービスである。 ストレージにアタッチするのではなく、マウントターゲットをAZに作成し、EC2インスタンスはそれを経由することでアクセスを可能にすることで、複数のEC2インスタンスの共有ストレージとして利用できる。 フルマネージド型サービスである NFSv4プロトコルを利用して、関連ツールや標準プロトコル/APIでアクセスすることができる ペタパイトまでスケーラブルにデータを蓄積することができる スループット/IOPS性能は自動的にスケーリングすることで低レイテンシーを維持する ファイルの減少に合わせて自動で拡張・縮小を行う 事前に容量を設定する必要はなく、従量課金となる データファイルは複数AZに分散して保存される ファイルシステムと呼ばれる管理単位を取る、これにディレクトリを作っていく マウントターゲットは固定のDNS名とIPアドレスを有していて、DNS名を使用してマウントすることで自動でIPアドレスが付与されるという仕組みになる 性能に関しては バースト込みで基本性能は100MB ファイル名は255バイト 1ファイルの最大容量は48TB インスタンスあたり128ユーザーまでの同時オープンが可能 何千もの同時アクセスが実現可能 1アカウントあたり1000まで AZあたりのマウントターゲットは1つまで マウントターゲットごとのSGは5まで ファイルシステムあたりのVPC数は1まで 各VPCのマウントターゲット数は400まで ユースケースは以下のように複数EC2インスタンスでデータを共有する必要がある案件となる。 EBSではできない、複数インスタンスからのストレージへの同時アクセスが必要である 数秒単位でのデータ追記が必要である フルマネージドで運用して簡易に利用したい アプリケーションの共有ディレクトリがほしい ビックデータなどの分散並列処理環境における共有データアクセスストレージとして利用したい コンテンツの共有リポジトリとして利用したい パフォーマンスモード その名の通りEFSのパフォーマンスを決める設定。 基本は汎用モードで、秒あたりのファイルシステム操作を7000に制限している レイテンシーは汎用モードのが低い 対して、最大I/Oモードは大量のクライアントからの同時アクセスが必要な大規模構築を行う際に利用する 最大I/Oモードは合計スループットを優先してスケールするようになるが、レイテンシーは長くなる バースト機能 ファイルストレージの負荷に対してスケーラブルに対応する機能。 以下のようなケースが例。 NFSサーバーの容量の増大によるスループット性能の低下が見込まれるとき 一時的なピーク時の負荷が増大する可能性があるとき バースト性能は以下の点から成り立つ。 バーストとは一時的な大量トラフィックの発生やそれに伴いサーバーなどの処理性能が一時的に向上することを指す バーストスループットモードにより、EFS側でファイルシステムの増大に伴ってスループットを自動的に拡張する クレジットシステムにより、ファイルシステムはバーストするタイミングを判断する 各ファイルシステムは、非アクティブであるかスループットが標準以下であるときにクレジットを蓄積することができる。 クレジットは通常ファイルシステムにおける読み書き処理の度に消費されるものであるが、蓄積されている場合はさらにそれを消費してバーストすることでスループットを拡張することができる 容量に応じたバースト性能となり、1TB以上の容量に応じて性能が向上する 最大で1GB(通常の性能は100MB)までバーストする 容量に応じてクレジットの蓄積量とスループット性能も向上する プロビジョンドスループット バーストが予期せぬ負荷に対してのスループット拡張出会ったのに対して、 こちらは一貫したスループットを事前に設定する方式で、API/AWS CLI/マネジメントコンソールから制御する。 1日1回だけ設定したスループット性能を減少させることができる。 EFS以外のファイルストレージ FSxタイプのファイルストレージをユースケースに応じてEFSに代わって選択することができる。 Amazon FSx For Windows File Server WindowsFile Serverと互換性のあるストレージでそのクラウド版といった感じ Windows上に構築され、Windows AD、OSやソフトウェアとの連携が豊富に可能なのが特徴 Active Directory統合などの幅広い管理機能を持つ SMBプロトコルによりEC2、VMware Cloud on AWS、Amazon WorkSpace、Amazon AppStream2.0等のインスタンスに幅広く接続可能である 最大数千台のコンピューティングインスタンスからアクセスが可能である ENI経由でアクセスし、VPCセキュリティーグループで制御を行う 単一AZの単一サブネットを指定して構成する 複数インスタンスでの共有や他AZ内のインスタンスからのアクセスも可能である マルチAZ構成を実施することもできる Amazon FSx For Lustre 分散型ファイルストレージであるLustreと互換性のある分散型の高速ストレージ 機械学習や高速コンピューティングのデータレイヤーに利用する一時的保存用の処理用ストレージとして利用できる スパコンに利用されているシステムであり、つまるところ高速コンピューティング処理を実現する分散・並列処理専用の超高性能なストレージである Lustreをフルマネージドで利用できる 最適容量3600GB、最大数百GB/秒のスループット、数百万IOPSまでスケールが可能である ENI/エンドポイント経由でアクセスする セキュリティグループで制御する 単一AZ、単一サブネットを指定して構成する S3とのシームレスな統合により、データレイク型のビックデータ処理や解析ソリューションに組み込む 増大するデータへの対応 ベストプラクティスの考え方のうちの1つ。 昨今はもうビッグデータとIoTから得られる大量のデータをどうこうすることが当たり前になってきているなか、インフラもそれに対応しないと行けないという話。 ビッグデータには様々なWebリソースから得られるものと、IoT機器から集められるものとがあり、それらを利用するためには解析・分析が必要でそのためには統計学的な話を抜きにしても収集したデータを蓄積しなければならない。 具体的には以下の通り。 効率的にデータを蓄積する(AWSサービスの例だと、S3・Glacier・Glue) 蓄積したデータをストリームデータとして処理する(Kinesis) ストリームデータを解析する(Athena、EMR、QuickSight、Redshift) こうしたビッグデータの蓄積にはDBの種類でもやったように、データウェアハウスとデータレイクという手法がある。 データウェアハウスは利用用途に応じてデータをETLで変換して蓄積するのに対して、データレイクは生のデータを出来得る限り用途によらず集められるだけ集めておくというスタイルになる。 以下にまとめておく。 DWH データ収集……構造化データを中心に、目的別データで必要なデータのみを抽出・収集する 蓄積……必要なデータのみ抽出・収集 処理・加工……事前に関連するデータ構造(スキーマ)に変換・蓄積、SQLで操作する 可視化分析……利用者がデータ分析やレポート内容などの利用目的を事前に特定して構築する フローは以下の通り。 目的別にデータを収集……販売データ、顧客データ、会計データ……etc ETLで目的やレポート形式に応じてデータを変換する ETLで変換したデータをデータウェアハウス型のDB等に蓄積 OLAP(Online Analytical Processing)やデータマートで活用される みそなのはETLで事前にデータを変換してから蓄積すること。 つまり、目的やレポート形式を明らかにしてそれに応じてETLを設定しないことには始まらないので詳細な設計等が必要であったりと構築に時間がかかる。 DL データ収集……生データ及び目的別データを構造化・非構造化・半構造化問わず収集する 蓄積……変換しないで生データ形式で保存するか、またはエッジ処理して保存する 処理・加工……事前にスキーマ定義(データ構造の定義)をしない。SQL・SAS・MapReduce・R・NoSQLなどで操作する 可視化分析……事前に目的を定義せず、ユーザがデータ郡から新たな価値を抽出し、データを解釈して活用する フローは以下の通り。 あらゆるデータを出来得る限り収集する 構造化データのみはETLでDWHへと蓄積し、それ以外の非構造化・半構造化データは適切なDB程度に蓄積する(こちらがデータレイクとなる) データマート・OLAP・ETL(Glue)・EMRを用いてApache Hadoop(大量データバッチ処理)、Apache Spark(ストリーミング処理)等で処理・加工される みそなのはDWHとは違って、構造化データ以外は生データのまま集めて、データの加工はあとからになるということ。 つまり、活用を目的として蓄積するのではなく、蓄積した結果必要に応じて加工して活用しようという発想なのだ。 Kinesis ストリームデータを収集・処理するためのフルマネージド型サービスで主に3つのサービスで構成されることになる。 Amazon Kinesis Data Streams……ストリームデータを処理するアプリケーションを構築する Amazon Kinesis Data Firehose……ストリームデータをS3やRedshiftなどへ簡単に配信できる Amazon Kinesis Data Analytics……ストリームデータを標準的なSQLクエリでリアルタイムに可視化・分析する Amazon Kinesis Data Streams ストリームデータ処理用の分析システムやアプリケーションを構築する。 実際にデータをどうストリームデータとして処理をするかというと、データ処理をシャーディング、つまり分散させて高速処理させることで行っている。 サンプルフローとしては IoT機器からデータを収集する Kinesis Streamsでストリーミングデータに加工する Spark Streamingで分析・加工する アプリケーションへデータが渡る というものになる。 で、このサービスはプロデューサー及びコンシューマという関係性を仲介する形で存在しているところが肝となる。 つまり、データを提供するサービスとそれを利用するサービスとを連携させ、ストリームデータを扱うということは大抵の場合それをリアルタイムで処理したいという目的があるので、それを助けるというのがこのサービスの主たる目的ということになる。 プロデューサー側の代表的なサービスや機能は Kinesis Appender Kinesis Producer Kinesis Agent……Kinesisサービスにデータを簡単に収集して取り込むOSSのスタンドアロンJavaアプリケーション AWS SDK Cloud Watch Fluentd……(個々のシステム毎の大量のログファイルの収集・解析・集約・保存を行うことができるデータコレクタ) AWS IoT となり、コンシューマーは Kinesis Firehose Kinesis Client Kinesis Analytics Lambda EMR Apache Storm となる。 またKinesisのその他関連機能としては Amazon Kinesis Producer Library(KPL)……Kinesis Streamsにデータを送信するOSS補助アプリ Eluent Plugin for Amazon Kinesis……イベント送信のプラグイン、これがないとStreamsやFirehoseによるデータの更新がうまく行かない Amazon Kinesis Data Generator(KDG)……こちらはテストデータを送信するためのプラグイン Amazon Kinesis Data Client Library(KCL)……Kinesisアプリケーションの作成を行う。OSSのクライアントライブラリでEC2インスタンスなどにデプロイすｒ Amazon Kinesis Data Firehose 各種DBに配信・蓄積するためのストリーム処理を実際に行うのがこちらの機能。 Lambdaと連携することによってETLとしても使うことができる。 Amazon Kinesis Data Analytics こちらはストリームデータを標準的なSQLクエリでリアルタイムに分析・解析を行うことができる機能。 FirehoseやStreamsからパスされた来たものをこちらで分析・解析を行い、再度FirehoseやStreamsへとパスするということもできる。 Redshift 高速でスケーラブルな費用対効果の高いマネージド型のDWH及びDL分析サービス。 概要は以下の通り。 数百ギガバイトのデータから開始して、ペタバイト以上まで拡張できる 1テラバイトあたり年間1000USD以下で利用できる 自動ワークロード管理など自動テーブルメンテナンスなど多くのメンテナンスタスクやデータ配置が自動化されている PostgreSQL五感の列指向データモデル 複数ノードをまとめたクラスター構成である 単一AZで起動し、マルチAZ構成は不可である RA3インスタンスで最大で他のクラウドデータウェアハウスの3倍に達するパフォーマンスがある AQUAによる分散キャッシュで、Redshiftが他のクラウドデータウェアハウスに比べて最大10倍の速度で動作する コンソールでクエリ実行ができる(クエリエディタ機能) 構成としては1~32個のノードにリーダーとコンピュートの役割を持たせ、クエリを実行し、ストレージへデータを保存するという形式になる。 リーダーノード……クエリのエンドポイントとなり、SQLコードの生成・実行を行う コンピューティングノード……リーダーからクエリを受け取り、複数ノードで並行して実行する。高速ローカルSSDキャッシュを持ち、同じクエリの場合はキャッシュを利用する。 マネージストレージ……クエリの実行の結果できたデータを保存しておく場所。クエリ実行時に必要なら取り出されることもある。永続データであり、専用のS3が作られる。 マネージストレージにはRedShift Spectrumという機能によって、自前のS3バケットを使ってそれを直接解析することもできる。 ただしこれには予め解析・分析目的をもったS3バケットを作っておく必要がある。 DBとしては以下の特徴がある。 列指向のRDBであり、大容量のデータアクセスを容易にしてディスクI/Oを効率化する データ圧縮によって読み込みデータ量を多くすることで処理を高速化する 分析ワークロードでブロック単位でデータを格納して、ディスクI/Oを効率化する データが格納されているブロックに対して、メタデータを付与して検索値とする リーダノードのインメモリ上にメタデータを格納する データのソート順をテーブルごとにソートキーとして指定する データ量とクエリ内容に応じてノードに対する分散処理を調整し、効率的で高速な処理を実現する キャッシュにより高速化を図る 頻繁に実行するクエリパターンは結合・フィルタ・集計・射影によって高速化する(マテリアライズドビュー) Redshiftのインスタンスタイプ 利用するデータサイズ及び増加予測に応じて2つのインスタンスタイプから選択する。 RA3インスタンス コンピューティング性能・マネージドストレージのスケーリング・支払いを独立させることでDWHを最適化する データ量の増大が想定される場合はRA3ノードの利用が推奨される 最低2ノードの利用が必要となる DC2インスタンス 固定ローカルSSDストレージを利用しているDWH データのサイズ増加に対してノードを追加し、クラスターのストレージ容量を増強する 未圧縮で1TB未満のデータセットの場合はDC2ノードタイプの利用が推奨される 最低1ノードの利用が必要となる WLM(ワークロード管理) ワークロード(システム処理に対する処理量や負荷のこと)に応じて複数のキューを設定し、クエリ割当ルールに基づいてキューを設定して、その優先順位を設定する。 キューはロングクエリ・ショートクエリと機械学習で自動的に区別され、設定されたキューにスロットを設置して、CPUとメモリを割り当てて実行する。 スロットが増えると並列度は向上するが、割当メモリ量は減少する。 Redshift運用の自動化 初期設定においてすでにCloudWatchのメトリクス取得が自動で実施され、コンソールで確認ができる 自動でバックアップは定期取得され、バックアップの実施時間も指定できる スナップショットはS3やRDSと同じく手動で取得可能 バッチの適用も自動で行われ、実施時間も指定可能 クラスターサイズの変更・一時停止・再開等のスケジュールも設定できる 機械学習によるクエリ効率化 クエリ実行は機械学習により効率化され、自動実行の補助もしてくれる。 テーブルの分散スタイルの自動最適化、統計情報の自動更新、データの再編成の自動実行等テーブルメンテナンスの自動化を図る 複数クエリの実行をワークロード管理で設定する際に、優先順位を自動で設定してくれる 機械学習アルゴリズムを使用して対象のクエリを1つ1つ分析し、クエリの実行時間を予測し、実行時間が短いクエリは優先して実行される WLMキューを削減可能 自動でクラスタパフォーマンスを分析し、最適化やコスト削減に対するレコメンデーションを実施する RedShiftのスケーリング RedShiftはノードのタイプ変更及び追加とクラスターの追加の2パターンでのスケーリングが可能。 ノードでのスケーリングはコンピューティングノードを追加することによってパフォーマンスの向上を図る クラスターの追加はConcurrency Scalingと呼ばれる機能によって、同時に複数のユーザー及びクエリからのリクエストに対し、クラスタを自動的に追加することで数倍の並行処理パフォーマンスを一時的に実現することができる クラスタの追加は10個まで RedShiftのデータ連携 他のAWSサービスとRedShiftの連携について。 連携する目的としては、RedShiftへデータを移動することで、DWHとしての解析基盤を集約化させるところにある。 まずはRedShiftが他のサービスからデータを取得する場合。 S3……1番使われる連携先。S3からデータを取得して解析するも、連携を前提にしてS3バケットを作って内部を直接解析してもよし Kinesis……Firehoseを利用して、ストリートデータの格納先としてRedShiftを指定することで、保存・解析に利用することが可能 RDS……直接の連携はないものの、PipelineやDMSを利用してデータ移行ができる DynamoDB……DynamoDBからRedShiftにデータコピーを実行できる Amazon EMR……EMRからRedShiftにデータコピーを実行できる 次に他のサービスへとデータを抽出する場合。 S3……UNLOADコマンドによって、S3にデータを抽出する QuickSight……データを可視化・解析してくれるBIツール、RedShiftに接続することで、データの可視化を実行可能 Machine Learning……RedShiftを機械学習のデータとして利用する RDS……PostgreSQL経由でデータを連携する AWS Glue データ抽出・変換・ロード(ETL)を行う完全マネージド型のサービス AWSサービスでETLを行いたいときはこちら。 Amazon EMR Apache Spark、Apache Hive、Prestoなどのビッグデータフレームワークを利用して、大量データを処理・分析するサービス。 AWS Lake Formation ここまでのサービスの中からデータレイク構成を構築するための補助ツール。 ベストプラクティスに従って構築していくことができる。 ハンズオン 今回はどれも高額だったので実際には構築はしなかった(万が一消し忘れたら20万は下らない)。 DynamoDB Aurora EFS マウントターゲットはAZに設置する。 ポリシーの設定。 このようにウィザード形式でチェックボックスを入れるとエディタにも反映される。 なので、予めウィザードでポリシーを作り、細かいところを自分でエディタで書き込むといったことも可能。 確認画面。 EFSはアクセスポイントを設定する必要があるので適宜設定をする。 セキュリティグループの設定も必要。 NFSへのトラフィックを許可するように設定する。 EFSの操作はクライアントツール等を使わないといけない。 下記のように立ち上げたEC2インスタンス内にパッケージをインストールするのが基本。 RedShift 1番性能が高いであろうRA3インスタンス。 月20万強は個人には高すぎる。 じゃあ1番安いDC2インスタンスならと思っても、月2万強。 うっかり気軽に作成して消し忘れようものなら怖い…… ちなみにノードを増設するとDC2でもさらに恐ろしい値段となる。 作成するにはいつものようにウィザードで。 デフォルトで勝手に作ってもらうこともできるし、VPCやサブネットグループを利用して自分で設定することもできる。 自分で作成する場合は利用するVPCにサブネットグループが存在していないと作成できないことに注意。

勉強前イメージ EC2 + 救援 やから、EC2になんかあった時に復旧させる的な？ 調査 EC2Rescue とは？ EC2インスタンスで動作する、トラブルシューティングツールになります。 Windowsのインスタンスに接続できなくなったり、起動ができなくなったなどの問題が発生した際に 分析・トラブルシューティングのためにログの収集を行うことが出来ます。 windowsインスタンスでは EC2Rescue for Windows Server を使用 Linuxインスタンスでは EC2Rescue for Linux を使用します。 EC2Rescue for Windows Server EC2Rescue for Windows Server では、以下が考えられるシナリオです。 ファイアウォールやネットワークインターフェースなど設定が原因のインスタンスへの接続の問題 ブートループなどOSの起動の問題 詳細なログ分析が必要な場合 また、以下のシステムでないと使えない可能性があります。 Windows Server 2008 R2 以降で実行されるインスタンス .NET Framework 3.5 SPI 以降がインストールされているインスタンス RDP 接続からアクセス可能なインスタンス EC2Rescue for Linux EC2Rescue for Linux では、以下が考えられるシナリオです。 vmstat、iostatなどレポートの収集 syslog、dmesgなど、ログと詳細の収集 ルートデバイスラベルの重複など、システムの問題の検出 OpenSSHファイルのアクセス許可の修正など自動的に修正 また、以下のシステムでないと使えない可能性があります。 Amazon Linux 2 Amazon Linux 2016.09+ SLES 12+ RHEL 7+ Ubuntu 16.04+ 勉強後イメージ イメージそのままやった。 OS壊れてももしかしたら復旧する可能性あるかもってことかな？ たまにAWSの障害でEC2壊れた時にもしかしたら使えるかもね？わかんないけど。 今回は手順とかは一旦なしにして、中身だけちょっと調べてみた。 参考 Linux 用 EC2Rescue を使用してオペレーティングシステムレベルの問題をトラブルシューティングする方法を教えてください。 EC2Rescue を使用して Amazon EC2 Windows インスタンスの問題をトラブルシューティングするにはどうすればよいですか? Amazon EC2RescueでEC2 Windows Server instanceを救出する

2021/06/15 はれ AWSのSecurityHubを有効化してみた。 数分経過した後、画面を更新したら、こうなった。 大体失敗していた。AWS Configを有効化しないとほぼ使い物にならないらしい。 タイトルをクリックすると、修復手順のページに飛べるようだ。 とりあえず、言われたとおりに設定する。ただし、SNSに関する設定はしなかった。ルールも何も選択せずに有効化した。 理由は、なんか面倒だったから。もう夜遅いし、俺は眠いのだ。 AWS Configが有効化されたことを見届け、俺は布団へ向かった････ (つづく？)