AWSをいじり倒す(9.CroudTrail、Athena)

前回からの引き続きで、CroudTrailを使ってVPCエンドポイントを使ったS3へのアクセス証跡を確認してみる

参考にしたのはこれ

S3のVPC Endpoint経由でアクセス出来ているか否かの確認 – Publicサブネット編 – サーバーワークスエンジニアブログ

CroudTrailは有効化しないとログ残らないのかな、と思っていたが

特に設定の必要はなく常時ONになっているようだ。

画面を開いてみると早速今までいじくりまわしてきた形跡が見えた。

一部切り取って確認してみる。

眺めていて気付いたのは

・バケットにオブジェクトをアップロードしたログ、というのは残ってない。

・EC2上でCLIによるBucket操作を行うと、ユーザ名はEC2のインスタンスIDになる。

（黒塗りのところはAWSコンソールから操作したので自分のユーザIDが表示されている）

という点。つまり、何でもかんでもCroudTrailに残るわけではないので、事前に目的のログが保存されるかどうかは確認しておかないといけないし、EC2に誰がアクセスしたかを別途把握する仕組みがないと追えなくなる。

具体的には、S3のオブジェクト操作ログは、

S3オブジェクトレベルのログ記録+監視方法 - Qiita

のようにオブジェクトレベルのログの記録を有効にする必要がある。

また、EC2のログはClowdWatch logsと連携させてログ記録+監視できる。

AWS構成パターン（CloudWatch Logs/EC2ログ管理）

このように調べたら何らかの対処法は出てくるけど、この辺は手探りで設定していくと検討漏れが出ること間違いなしなので、構築ノウハウを記載した書籍等を読んで所謂ベストプラクティスなやり方を身に付けた方が良さそうだ。

資格対策本ではこの辺はカバーできないなぁ。

さて改めて、

・S3にエンドポイント経由のアクセスができているかどうか

・ついでにオブジェクトレベルのログ記録ができるかどうか

の２点を確認することにする。

 S3にエンドポイント経由のアクセスができているかどうか

エンドポイントのない状態でバケット作成・削除→エンドポイント作成→バケット作成・削除のログ。

エンドポイント作成前のCroudTrailのイベント情報

ログ詳細を頑張って見なくても、発信元IPがパブリックIPになっているので、

これでもう十分インターネット経由ってわかりそう

エンドポイント作成後

発信元IPアドレスがローカルになっている。 

やはりこれだけでちゃんと機能しているとわかってしまった。

寂しいのでログ詳細も見てみると

エンドポイントなし

エンドポイントあり

 vpnEndpointIdってのが増えていることがわかる。

通信時間に大した差がないのは前記事の通りだが、

エンドポイント経由かどうかで料金が変わってくるので、

エンドポイント設定後は一度ぐらいこのログを見て安心した方が良いと思う。

オブジェクトレベルのログの記録

このオブジェクトレベルのログというのは

今まで見ていたイベント履歴にログが増えるわけではなく、

証跡情報として指定したS3バケットに保存される形式になるようだ。

まずはログ保存用のバケットをサクッと作る

そしてログ保存の設定。

CroudTrailの証跡の作成から

証跡情報の作成

証跡名は適当に。

別リージョンからアクセスすることはないので、

全てのリージョンに→いいえ

管理イベントはとりあえず全部記録したいので「すべて」「はい」

Insightsイベント

書き込み管理APIの異常な呼び出しボリュームとはいったい

CloudTrail Insights の発表: 異常な API アクティビティの特定とそれへの対応 | Amazon Web Services ブログ

スムーズに実行されている場合のログエントリは、さながら工場で安定して響く安心感のある機械音のようなものです。しかし不具合が発生した際には、その音が邪魔になりどの機器に不具合があるのかが聞き取りにくくなります。ログデータの量が膨大になる可能性があるような大規模なソフトウェアシステムでも、同じことが言えます。その記録を精査して実用的な情報を見つけるのは骨が折れる仕事です

ぐうわかる・・・

で、その中から異常なアクティビティを発見してくれる機能ってことらしい。

お値段安かったら有効にしてもいいと思うけど

CloudTrail Insights では、Insight タイプごとに分析された書き込み管理イベントについて、100,000 イベントごとに 0.35 USD の料金が請求されます。

100000イベント・・・が多いかどうかはシステムの規模にも依るのでなんとも。

データイベント

記録したいS3バケットを指定することができる。

てっきりS3の設定画面からログ記録の有効化するのかと思ったけど、

CroudTrail側から設定できるみたいだ。

S3バケットの追加からバケットを選択

ストレージの場所

ログの保存先S3。さっき作ったS3バケットを指定。

プレフィックスで指定した場所にたまっていく模様

ログファイルの検証とは、ログの改竄がないかどうかをチェックする仕組み。

できた。

S3の設定を見に行くと、オブジェクトレベルのログ記録が有効になっている

さっそくオブジェクト操作をしてみる

確認、削除、アップロードを行った。

 念の為、S3のGUIから手動でも適当なファイルをアップロードダウンロードを行っておく

〜１０分後〜

ログの生成を確認。保存先の階層が結構深い

json形式が.gzで保存されているので、ローカルに落として解凍し

中身を見てみる

わかりにくっ！

これはこうやって読むものじゃないな

これによるとAthenaで読むのが良いみたい。

CloudTrailでS3オブジェクトレベルのログを取得してAthenaで閲覧してみた | Developers.IO

そもそもAthenaってなんだ

Amazon Athena とは - Amazon Athena

標準 SQL を使用して Amazon Simple Storage Service (Amazon S3) でのデータの直接分析を簡易化するインタラクティブなクエリサービスです。

めちゃめちゃ限定的ィ！

それだけS3のログはよく利用されるってことなのかな。

早速、CroudTrailのイベント履歴からAmazon Athenaで高度なクエリを実行

保存場所を選ぶ。この時のSQLのクエリは自動で作ってくれている。

ここで自動生成されるAthenaテーブル名は後で使う。

できたようなのでAthenaに移動

Athenaの画面。

まずはSettingsで、Athenaクエリ実行結果を保存するS3バケットを指定。

クエリを作成。

参考記事からコピペしたものをベースに、日付とテーブル名を変更。

テーブル名はさきほど表示されていたものを使用。

左のメニューにも表示されてるけどね。

ところでこのクエリの書き方って、どうやって学ぶんだろう・・・。

自動生成する方法は見当たらないので、いじくってたらだんだん覚えていく系かしら

 Save asでクエリを保存。

Run queryで実行してみると・・・

あれ？GUIから出し入れしたログのみが出てきて、

EC2からCLIで操作したログがでてこない・・・。

仕方ないのでログファイルを直接頑張って読んでみることにする

eventNameがDeleteObject・・・これはrmしたときのログだろう。

一方でcpしたときは

UploadPartに
 

CreateMultipartUploadに

CompleteMultipartUpload

という３種類が出てきている。
 

みるべきキーワードが分かってきたので、クエリを変更してみる。

GetObject,DeleteObjectに加えて上記の３種イベントを追加。

また、ログに

と書いてあったので、

and useridentity.type = 'IAMUser';

の条件では引っ掛からなくなると思い、削除した。

このクエリの実行結果はこちら。

で、このUploadpartとは、

つまるところ適当に30MBのファイルをアップロードしてしまったせいで

図らずしもこのマルチパートアップロードを行ってしまったらしい

Amazon S3 マルチパートアップロード CLI

大きなファイルをアップロードするときに分割する機能。

cpコマンドを使うと自動でマルチパートになるんだと。

 これは１パートあたり５MB以上、最大１００００パートまでという仕様。

Amazon S3 マルチパートアップロードの制限 - Amazon Simple Storage Service

今回30Mのアップロードは４分割されてるっぽいので、8M前後に勝手に分けられたと推測。ログをよく読むとそれも書いてあった。

これが１つと

これが３つ。

いい具合に分割して送ってくれてたのね。

順番としては

CreateMultipartUpload→Uploadpart*4→CompleteMultipartUpload

なんだろうけど、順番通りログがでてないのは謎。

ログはコンマ0秒以下は残ってないので、仕方ないのかなぁ。

で、小さいファイルならCLIでもPutObjectになるんだよね？

ってことで1KBのファイルを作ってcpしてみる

結果。

無事PutObjectになった。

S3に複数人でファイルやりとりするとなったら、

やっぱ出し入れの情報は見たいし、オブジェクトレベルでのログ確認は必須だろうなぁ

ということでS3の操作から始まって、AWS CLI、VPCエンドポイント、CroudTrail、Amazon Athena、マルチパートアップロードと色々話が広がって勉強になった。

進捗

AWSをいじり倒す(8.AWS CLI)

以下を参考にCLIでs3を操作する。

AWS CLIを使ってEC2のファイルをS3へアップロードしよう | Avintonジャパン株式会社

ゆくゆくはCLIマスターして、JSONでポリシーかけるマンになりたいなぁ。

環境としては、自PCから専用のIAMユーザとしてアクセスする方法と

EC2に操作したい対象のサービスのIAMロールをアタッチしてアクセスする方法がある。

VPC作って、VPC内で通信を完結させることも多いので

基本的には後者のほうがよさそう。

S3を操作したいので、今回はS3FullAccessをアタッチする。

EFSの時に作ったEC2にアタッチ済みのロールに追加（手抜き）

AWS CLIツールはEC2(Amazon Linux)なら最初から入っているのでインストールは

不要。

EC2を立ち上げ、アクセスしconfig変更。

今回アクセスキーは使わないのでNone
EC2のリージョン名はいろんな確認方法があると思うが

DNSとかにも埋め込まれているのでそれ見て抽出

出力はjsonがおすすめらしい

configの格納場所も確認

VPCの確認コマンドを打つとエラー

権限を付与していないので、当然。

UnauthorizedOperationって出た時はIAMロールを見直す必要がある。

当該EC2にアタッチ中のロールに追加で２ポリシーをアタッチ

VPCReadOnlyAccessがあれば上記コマンドは通るはず。

早速試すと・・・通った。再アタッチとかは必要なくて即時反映

EC2ReadOnlyAccess権限も付与したので、インスタンス情報も取得可能

aws helpコマンドでヘルプが読めるけど

awsの後に続くコマンドはめちゃめちゃ種類が多いので

やりたいことがある都度ネットで調べた方が早そう。

早速、前回作ったS3バケットにファイルを入れてみる。

test-s3-12345は前回つくったバケットの名前

特に問題なく移動できた

バケットそのものを作る

バケットを削除する

思いの外簡単で、詰まるところがない。

--forceオプションで中身があっても強制削除できる。

次に、VPCエンドポイントの効力を確認してみる。

すでにVPC作る時にS3へのエンドポイントを作ってしまっていたので、

まずはエンドポイントありの時間を計測

３０MBの空ファイルを作成

timeで計測

VPCのS3向けエンドポイントを削除する

削除すると、ルートテーブルからも消えた。賢い。

一旦消して、再度送信すると・・・

変わ・・・らない！？

EC2はオハイオ、S3もオハイオの状況だとAWS内部を通すも外部を通すも

転送速度としてはそんなに変わらないのかもしれない・・・。

探していると、同じく確認しようとしている記事を見つけた。

S3のVPC Endpoint経由でアクセス出来ているか否かの確認 – Publicサブネット編 – サーバーワークスエンジニアブログ

なるほど、CroudTrailか。次回CroudTrailを触ってみることにする。

進捗

AWSをいじり倒す(7.S3)

S3を使ってみる。

バケットを作成ボタンを押す。

設定

バケット名は適当に、一意に。全S3ユーザで一意なので、生半可な名前は被るw

リージョンは改めてここで選択。

testにつかっているEC2サーバと同じリージョンにする

パブリックアクセスの設定

基本的にはブロック推奨らしい。

日本語変だなぁ・・・

いったんブロックで作って、余力があったらパブリックも試すことにする。

S3で誤ったデータの公開を防ぐパブリックアクセス設定機能が追加されました | Developers.IO

S3のアクセス制御はなかなか奥が深そう

オブジェクトのロック

今回は無効。

これで作成。設定項目少ないな〜

できたっぽい。

フォルダの作成

フォルダ名を入れて作成

暗号化についてこの辺が参考になる

S3 オブジェクトに暗号化を追加する方法 - Amazon Simple Storage Service

できた。

アップロードしてみる

う〜ん直感的。書くことがないぐらい。

適当に画像をD&Dで追加

アクセス設定

このユーザーIDって誰やねんと思ったら、自分のことらしい。

プロパティの設定。

勘違いしていたけど、バケットに対してストレージが割り当てられるんじゃなくて

オブジェクトに対してストレージの種類を割り当てる感じなのね。

暗号化とメタデータ

メタデータのヘッダーについて

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/user-guide/add-object-metadata.html

上図のようにアップロードしようとしているファイルのヘッダーを変更したり、AWSオリジナルヘッダーを追加したりできる。

タグはNameを指定してみたが・・・S3ではそういう使い方ではないみたい。

他のサービスで使うようなタグというよりは、ポリシーの対象グループとするなど、もう少し高級な使われ方をするようだ

S3 オブジェクトのタグ付け機能を使ってみた – サーバーワークスエンジニアブログ

アップロードボタンを押してアップロード

できた。

ただ、あんまりGUI上で操作しているような記事を見かけず

CLIでの操作が主流。

次回、AWS CLIを使って、CLIでの操作にトライする

AWSをいじり倒す(6.EFS)

EFSを使ってみる。

以前、複数のWindowsサーバをEC2で立ち上げて、

ファイル共有したいなぁと思って調べた時に出てきたキーワードだけど

EFSはWIndows対応してなくて使えなかった。

blackbeltみてても結構大きくWIndows非対応と書いてあるので、今後も対応することはないのだろう・・・。

（ちなみにその時は多めにEBSを積んだEC2をストレージ用として建て、別EC2からネットワークドライブとしてマウントした。）

調べてみると、気合でWindowsから使う方法もあるにはあるみたいだが、

今回はLinuxサーバを２つたてて、それぞれにEFSをマウントし、ファイル共有を試す

AWS EFS をEC2にマウントしてみる - Qiita

これが参考になりそう

サービスからEFSを選択した最初の画面

ネットワーク設定

アクセスしたいEC2の所属するVPCを指定する。

マウントターゲットの設定

セキュリティグループはデフォルトで何か入っているが、今までの経験からするとうまく機能しないと思われるので、要確認。

タグの設定

なんでか説明が詳しくて、Nameがデフォルトで入っている

ライフサイクル管理

EFSにはスタンダードと定頻度アクセスという２種類のストレージがある

EFS ストレージクラス - Amazon Elastic File System

ただ、定頻度を最初から指定できるわけではなく、このライフサイクル管理によって指定した期間アクセスがないと自動で移動されるような使い方になる

選択肢はこんな感じ。

長期保存となるものはなるべくS3に保存すべきなんだろうけど、

使うと思ってたけど実は使わない、みたいなものがあるとしたら

有効にしといて損はない機能かな。

スループットモードの選択

バーストは、普段貯金しておいて突発的な支出に備えるモードであるが

貯金で買えない量のトラフィックが必要ならプロビジョニングモード。

この辺はblackbeltP66あたり参照

パフォーマンスモード

最大I/Oを使うべきかどうかはClowdWatchあたりで監視してないとわからん気がする

暗号化

暗号化を有効にすると、保管されているデータの暗号化はともかく

転送中のデータ暗号化は証明書の準備など、設定がややこしくなる。

インターネット越しにEFSと通信する時とかに必要になってきそう。

同一VPC内のEC2との通信であれば不要かな。

Amazon Elastic File System（EFS）を使ううえでの勘所 - Qiita

デフォルトでいろんな制限しておいて、IDベースで権限を上書きして使う。

 これはこの辺が参考になった

[アップデート] Amazon EFSでIAM認証とアクセスポイントの設定が可能に | Developers.IO

試しに、読み取り専用アクセスを強制にチェック。

ポリシーの設定を押して

JSONの画面を出して、保存する。ここまでしないと反映されない。

アクセスポイント

アクセス権限付きのディレクトリ を作成するイメージ。

先ほどと同じ

[アップデート] Amazon EFSでIAM認証とアクセスポイントの設定が可能に | Developers.IO

が参考になる。見様見真似で２個ディレクトリ を作成

確認画面を経て、作成。

割とすぐできた

上の画像に見えているファイルシステムIDを使ってマウントすることになる。

セキュリティグループの確認

入ってるのはデフォルトのガバガバ設定だった。

なんか作る時は先にセキュリティグループを作らんとあかんかも。

NFSは2049のTCP。

ルールを作って

ファイルシステムアクセスの管理から

新たにセキュリティグループを選択して保存

接続確認をしていく。

接続したいEC2に、Linux NFSv4 Clientのインストールが必要。

EFSマウントヘルパーというのがamazon-efs-utilsに含まれており、これを使うことが推奨されている

sudo yum –y install amazon-efs-utils

特に問題なくインストールできた。

さてマウント。

怒られた。

どうもこの指定したファイルシステムIDからドメイン名を生成して、

ドメイン名からマウント対象のEFSを探してくる挙動みたいなのだが

DNSの解決ができねーぞ、と。

【AWS】EC2からEFSをマウントする - MOテクノロジー

久々にVPCの画面を開いてDNS設定を確認

DNS解決の編集・・・すでに有効

DNSホスト名の編集

チェックついていなかったので、有効化

・・・で、DNSホスト名の編集って何？

VPC での DNS の使用 - Amazon Virtual Private Cloud

パブリック IP アドレスを持つインスタンスが、対応するパブリック DNS ホスト名を取得するかどうか示します。

この属性が true の場合、VPC 内のインスタンスは DNS ホスト名を取得しますが、これは enableDnsSupport 属性も true に設定されている場合のみです。

今回のEFSはパブリックIPなんて持ってないはずなんだけど・・・。

パブリックDNSって関係なくない？

これで結果が変わる理由がよくわからないままコマンドが・・・通った。

念の為nslookup

ローカルIPだよなぁ。モヤモヤ

気を取り直して、アクセス制限を確認する。

想定通り。

EC2用のロールを作成

ロールの作成

EC2を選ぶ

今回必要なのはElasticFileSystemでClientでRead/Writeなので

これを選択。

タグに適当に名前をつけて、作成。

できた。

EC2の画面を出して、ロールのアタッチ

先ほど作ったロールを選択。

さて、これで本当にいけるんだろうか。

いったんEFSをアンマウントして、iamを指定してマウントする

ファイルを作ってみると・・・

いけた！

アクセスポイントも試してみる。

read-onlyのアクセスポイントにマウントしたら、書き込みが不可となった。

 

違うEC2を建てて、マウントしてみると今まで作ったファイルが見えた。

試し忘れたけど、EC2再起動するとマウント状態も解除されてしまうので

永続的にマウントするには追加設定が必要

Amazon EFS ファイルシステムを自動的にマウントする - Amazon Elastic File System

Linux系をメインで使うときの共有ストレージとしては、気軽にアタッチできて使いやすいかも。

でもSMB対応のストレージも欲しいなぁ

進捗

AWSをいじり倒す(5-2.RDS-Aurora)

Auroraを選んでみる。

簡単作成を選びたい気持ちを抑えて、勉強のために標準作成

Auroraを選ぶ

互換性はMySQLを選ぶ

互換性とはなんぞや？

よくある質問 - Amazon Aurora | AWS

 MySQL データベースで使用しているほとんどのコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します

なるほど。ということはテスト接続はMySQLと同じコマンドで試そう。

 機能を４つから選ぶ

サーバーレス気になる

Aurora Serverless の仕組み - Amazon Aurora

ワークロードの集中が数分または数時間しか続かない場合やアクティビティが低下したり完全になくなったりする期間が長く続く場合

が用途として適しているらしい。今回アクティビティなんて無いに等しいので

サーバレスのほうがいいのかも。

しかし、サーバレスって言うけど必要に応じたリソース分のサーバは結局あるわけだし、この単語どうにかならんかな。

文句言いながらサーバレスを選んでみることにした

設定

パスワード自動生成はしないぞ。

キャパシティー設定

この辺がサーバレス特有の設定

キャパシティユニットは2の累乗刻みで1〜256まで選べる。

今回は1〜2の最小構成でいく。

強制的にスケーリング・・・のところはタイムアウトって何だ

[アップデート] Aurora Serverless の最小キャパシティが 1 から指定可能になりました！＆キャパシティ変更の強制オプションが追加されました | Developers.IO

ただし、以下のような場合には、スケーリングポイントが特定できず、タイムアウトになることがあります。

• 進行中の長期のクエリやトランザクションがある場合
• 一時テーブルやテーブルロックを使用している場合

なるほど。

アイドルの一時停止も便利そうだけど、今回はどちらのオプションもなしで。

接続

この辺は前回と一緒。

APIの項目が増えている

Aurora Serverless の Data API の使用 - Amazon Aurora

この API を使用すると、ウェブサービスベースのアプリケーション（AWS Lambda、AWS AppSync、AWS Cloud9 など）を通じて Aurora Serverless にアクセスできます

無料なら有効にしない手はない。普通にEC2を介せばコマンド発行できるんだろうけど、徹底的にコスト削りたい時には良いかも 

追加設定

 前回と一緒

ちなみにAuroraは暗号化がデフォルトで有効である（画像は割愛）

以上で設定おわり。データベースの作成ボタンを押す。

２回目なので標準作成でもサクサク選べた感はある。

作成中の様子

せっかくなので認証情報のところを押してみる

ここに自動生成のパスワードも出るわけね。

できたので接続してみよう

まずは前回と同じく建てたEC2サーバに接続.

mysqlデータベースに接続するコマンド、これも前回と同じもので

アクセス先を今回のAuroraにしたものを投入すると

普通につながった。 

 Aurora要素は微塵も感じられない

うーん操作感はMySQLと同じ。

あとはレプリカを作ってみようと思ったが、作成するメニューがない。

Aurora Serverlessが一般利用可能になったので試してみた | Developers.IO

Aurora Serverlessでは以下の機能をサポートしていません。

• S３バケットからのデータロード
• Amazon Aurora MySQL DB クラスターからの Lambda 関数の呼び出し
• 高度な監査の使用
• Auroraレプリカ

使えなかった・・・！

レプリカ作って負荷分散する思想と、負荷に応じて性能を拡張する思想は相容れないのかもしれないが、読む専用のリードレプリカの存在があった方が安心する（精神論）

というか、下記のダウンタイムが許容できない場合はサーバレスは使えんということになる。

AuroraかRDSどちらを選ぶべきか比較する話をDevelopers.IO 2019 in OSAKAでしました #cmdevio | Developers.IO

シングルインスタンス構成で、そのインスタンスがクラッシュした際のことを考えます。この場合、Auroraはインスタンスの自動復旧を行ないます。この復旧は通常10分未満で完了します。この10分のダウンタイムを許容できるのであれば、Mulit-AZにせずとも良いのではないでしょうか

しょうがないのでこのDBは消して新たに作成する。

今度はこちらを選ぶ。

すると新たなメニューが登場

これを選べばレプリカも最初から作成されるのかな？

早速作ってみると

２つ作成された・・・と思いきや、ロールが読み込みと書き込みで別。

エンドポイントは２つなので、これはいわゆるリードレプリカは１つで

書き込み権限のあるエンドポイントがマスターということか。

リーダーの追加でレプリカを増やしてみる

DB クラスターに Aurora レプリカを追加する - Amazon Aurora

設定画面

上では2cを選んでいるけど、

2cにサブネット作ってなくて怒られたので、のちに2bに変更

暗号化は触るところなし（画像は割愛）

設定

ソースには別のレプリカも選べる。

フェイルオーバー

本体が死んだとき、だれがプライマリになるかの優先度決め

プライオリティ"範囲"って、なんで範囲？

普通にプライオリティ値でいいのでは・・・。

この辺は特にいじる必要なし

パフォーマンスインサイト

Performance Insights を使用した Amazon RDS データベースの負荷分析 | Amazon Web Services ブログ

データベースの負荷（どのSQL文が負荷を発生させており、それはなぜなのか）を可視化するダッシュボードを使用して、エキスパートな方とエキスパートではない方の両方が、Performance Insights でパフォーマンス問題を容易に検出できます。

これは調子悪い時に有効にすれば原因がわかるかも。

メンテナンスも特に変更なし 

Add readerして、ロール：読み込みのレプリカが増えた。

結論としては、AuroraもMySQLも、使用感は同じ。コマンドレベルで同じ。

なので構成や挙動、お値段の違いを勉強して

最適な環境を選べるようにしましょう、という感じ。

何度か引用したこの記事によると

AuroraかRDSどちらを選ぶべきか比較する話をDevelopers.IO 2019 in OSAKAでしました #cmdevio | Developers.IO

ちょっと屁理屈に聞こえるかもしれませんが…たしかにAuroraの方がAWS利用費は高くなるかもしれませんが、その分人的コストを抑えれますよ？という話です。

結局こう書いてあるので、ちょい使いならMySQL、がっつりだとAuroraかなぁ（個人の感想です）

進捗

次はストレージ付近触ってみようかな

AWSをいじり倒す(5.RDS-MySQL)

RDSを作ってみる。今回はMySQLで作る。

RDSの画面からスタート。

データベースの作成

次の画面

簡単作成なるものができたらしい。

使うだけならこっちでいいのかも。

今回は標準作成でいく。

Auroraの猛プッシュをよくみるので使ってみたいけど、今回はMySQL

テンプレート を選ぶ

MySQL - AWSのRDSデータベース作成時の設定について｜teratail

単に無料枠は時間やサイズに制限があるだけみたい。今回は無料枠でOK

設定

インスタンス識別子はtest-database-1に。

ユーザ名は、今回はadminでいいか。

パスワードはせっかくだから自動生成してもらおうかな。

でも、どこでパスワード確認するんだろうか（要確認その１）

DBインスタンスサイズ

無料枠だと、ここがまったく選びしろなく固定となるようだ。

（試しに本番用を選ぶと選択肢が増えた）

ストレージ

割り当てはSSD/20GBでいいとして

自動スケーリングはこれ日本語変だな？？

「指定したしきい値を超えた場合にストレージを増やす」と書いてあるのに

「最大ストレージしきい値」を書けって。しきい値って言葉の使い方おかしくない？

【DBのディスクサイズ管理が簡単に】RDSのストレージがストレージの自動スケーリングをサポートしました！ | Developers.IO

これによると、例えば上の画像の設定だとMAX1000GiBまで増やすという意味でOKらしい。

拡張のタイミング＝いわゆるしきい値は勝手に考えてくれるんだろう。

可用性と耐久性

無料枠では選べないらしい。本番環境だと必須だろうなぁ

接続

VPCを指定する。

いろんなサービスでVPC指定しろと出てくるところを見ると、

AWSで何かしようと思ったらまずはVPCを作るところから取り掛かるのがよさそう。

追加の接続設定

サブネットグループ・・・RDSが使えるサブネットを指定するところ。既存のグループを選ぶとかはできない。新しいDBサブネットグループの作成、ということは新たなサブネットが生成されるのか？（要確認その２）

パブリックアクセス可能・・・同一VPC内にEC2を作るつもりなので、なし

VPCセキュリティグループ・・・説明を読む限りRDS用に作った方がよさげだが、ここでは名前しか付けられない。設定は自動なのか？（要確認その３）

データベースポートはこのまま。

以下のような感じに設定

認証

選びしろなし

追加設定

最初のデータベース名。

ここで名前入れておけばデフォルトでDBを用意してくれるようだ

適当にtest-mydbとしようと思ったら、ここは英字、数字と _ 以外

だめらしい。test_mydbにする。

バックアップ

保持期間は７日もいらないので１日にしておく

モニタリング

せっかくだからモニタリングは有効に。有料だけど。

ログのエクスポート

どんなタイミングで何のログがでるのかわからないので、全チェック

メンテナンス

メンテナンス中のダウンタイムについては以下。

必要とされる Amazon RDS メンテナンス中のダウンタイムを最小限に抑える

何をメンテナンスするか＋マルチAZかどうかによってダウンタイムの影響が変わるが

完全０にはならないぽい。

使えない時間が存在する前提で運用しないとだめということか。

削除保護

今回は消えてもヨシ！

これでやっとこさ設定が完了。こりゃ長いわ・・・。

簡単作成ボタンができたのも頷ける。

データベース作成ボタンを押して完了。

作成中・・・。

識別子のところクリックするとステータスが情報欄でわかる。作成中

バックアップ中・・・

数分と書いてあるけど、結構時間かかるなあ。

利用可能。

さて、要確認事項をみていく

（要確認その１）自動生成されたパスワードはどこに？

ステップ 1: RDS DB インスタンスの作成 - Amazon Relational Database Service

[Auto generate a password (パスワードの自動生成)] – このオプションは無効にします。

公式ガイドが自動生成使ってなくて草

 そうこうしているうちに、パスワードのありかの記載を見つけた

DB クラスターを作成して Aurora MySQL DB クラスターのデータベースに接続する - Amazon Aurora

確かに作成中に青い帯出てた！でももう消えてるがな！！！オワタ

落ち着いて、ここの変更ボタンから

パスワードの再設定を行う。

変更をすぐやってしまうかどうか

もちろんすぐ変更。

自動生成、なんもいいことないじゃん・・・。

（要確認その２）サブネットはどう切られたのか

なんだか知らない子が２人いますね。

クリックしてみると

いや知ってる子やん。自分で作ったサブネットが列挙されているだけっぽい。

「新しい」DBサブネットグループの作成とは一体・・・。

（要確認その３）セキュリティグループ

なんじゃこりゃ案件。

パブリックアクセスは無しにしたのに、自宅のグローバルIPソースでのアクセス許可設定が入っている上に、VPC内からのアクセス許可はなし。全然違う。

以下のように書き換えた。

なんでこんな初期設定になってたのか謎。

自動で作ってくれる系はありがたいこともあるけど、チェックはしないといけないなぁ 

次に、リードレプリカを作成する。本体からコピーされた読み取り専用のRDS。

設定画面。

この辺はそのままでよさげ。

マルチAZ配置のところ、リードレプリカのさらにスタンバイの作成もできるのね

ネットワーク＆セキュリティ

AZに本体とは別のAZ（2b）を指定。他はこのままでよさそう

暗号化はなし

設定

DBインスタンス識別子に適当な名前を入力。

なんか赤線入ったんですけど、また僕何かやっちゃいました？

何いれてもこの赤線が消えないので無視

ポートはそのまま

モニタリング

はリードレプリカまではしなくていいか。

ログは全チェック

メンテナンス

自動アップグレードの通知を受け取るかどうか。後からオフにもできる

以上で設定完了、作成ボタンを押す。

できてるできてる。

さて、接続確認を行っていく

RDSに接続するためのEC2を立ち上げて、SSHで接続する

そこから、RDSに繋いでみる。

接続先はRDSの画面から確認できるエンドポイント

まずEC2にmySQLクライアントをインストール

sudo yum -y install mysql

次に、データベースに接続

mysql -h test-database-1.ccoqjumqewod.us-east-2.rds.amazonaws.com -u admin -p

パスワードを入力すると・・・

お、つながった。

データベース一覧を表示するコマンドを投入

show databases;

おー、test_mydbもちゃんとできてる。

 中身は空っぽなんですけどね。

リードレプリカにも繋いでみる。

エンドポイントを確認して

接続コマンド投下

読み取り専用である事の確認

試しにテーブルを作ろうとすると怒られた。

確かにリードレプリカだ。

メインの方でテーブルを作ってみる

これをリードレプリカ上で確認すると、ちゃんとコピーされていた。

しかし、慣れてなさすぎてセミコロン打ち忘れ多すぎわろた。

 データベースの扱い方自体もそのうち勉強せねばならんが、

今回はRDSを使うまでが目標なので、このくらいにしておく。

拡張モニタリングを有効にしたので、様子をみてみる。

CloudWatchさんが働いている模様

って、プルダウンから選ばないと拡張モニタリングにはならんらしい。

上のは無料で見れるんか

拡張モニタリングをオフにすれば、無料枠におさまるはずなので、オフにしておく。

しかし、わざわざRecommendationsで拡張モニタリングいいぞーっていうぐらいなので、本格運用時はオンのほうがいいのかなぁ。

データベースの停止も試す。

リードレプリカを先に削除、

結構厳重やな。

本体を削除。

スナップショットを残してくれる、と。

お試しなので別にいらんのだけど、保存のされ方を確認するために残しておく

できた。EC2でいうAMIみたいなものかな。

いらないので削除を選んだら、一瞬で消えた。

進捗

BLEのsnifferを作成する

仕事でBLE通信を扱うので、こちらも勉強を始めた。

Bluetooth Low Energyをはじめよう

とりあえずこの本を読んでみたが、専門用語が多く正直理解度はまだまだ。

ただ、WiresharkでBLEがパケットキャプチャできるツールが紹介されていたので

それを試してみることにした。

nRF Sniffer for Bluetooth LE - nordicsemi.com

パケットの息吹を感じれば理解も深まるはず

ということでRequired HardwareとなっているnRF52840 DKを入手。

海外から送られてきて１週間ぐらいで届いた。

ラズパイっぽい本体と、よくわからんタグが箱に入ってた。

正直この辺はど素人なので手探り感満載でセットアップしていく。

この英語のドキュメントをたぐればなんとかなると信じて。

Nordic Semiconductor Infocenter

Minimum requirements

この中で準備が必要そうなのはSEGGER J-Link Software

https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPack

こちらのここからダウンロード。

今回はmacでやります

インストール開始

特に難しいところはないので割愛

NFC・・・え、もしかしてこのタグみたいなやつがNFC??

ささった・・・！

といってもこれ、スマホにnRF Toolboxというアプリをインストールするためだけっぽいので正直いらなかったかも（以降も特に出番なし）

a.PCとUSBケーブルでつなぐ→OK

b.SW9をVDDに。最初からVDDっぽい

c.SW8をON!

LEDが光り出した。

PCに認識された。

ここから用途に応じてソフト落としてこいってことかな？

今回はsniffer目的なのでこいつをダウンロード

nRF Sniffer for Bluetooth LE - nordicsemi.com

→nrf_sniffer_for_bluetooth_le_3.0.0_129d2b3.zipを入手。

次に、nRF snifferのファームウェアを

nRF Connect Programmerというソフトで書き込む。

nRF Connect for Desktop - nordicsemi.com

Programmerを選択

左上のselect deviceで今繋いでいるボードを選択

Readを押すとメモリの中身が見えるらしい。

何か出たけどなるほどわからん。

Add HEX fileでファームを選択。

HEXファイルは先ほどダウンロードした

nrf_sniffer_for_bluetooth_le_3.0.0_129d2b3.zipの中にある

って・・・いっぱいある！どれやねん。

ドキュメントをよくよく探したら書いてあった。

今回52840を使っているので、PCA10056か。

選んだらこうなった。

左がBefore,右がAfter。中身は相変わらずわからんけども

Erase & writeで書き込み。

再度READしたら左と右の図の吹き出しに書いてあることが同じになったので、書き込めたっぽいw

次のステップへ

コマンドウィンドウでhexファイルのあった隣のフォルダ、extcapフォルダに移動

pip3 install -r requirements.txt

を実行。（PCにpythonがインストールされていることが前提。）

するっといくかと思いきや

Xcodeのライセンスに承諾しろと。

長々したライセンス文を読んだら承諾コマンドが最後に書いてあったので実行

って打ったら別の文章を読めとでてきたw

次の文章もハイハイと読んで

最後にagreeと打ってOKになったっぽい。

あらためてpip3 install -r requirements.txt実行。

sudoしてなくて怒られたのはさておき無事インストール完了。

Wiresharkを起動。（←入ってない人は別途インストール要）

Wireshark > About Wireshark(Macの場合)

からfoldersを選択

このURLをクリックして開いたフォルダに、extcapフォルダ内のデータをコピー

コマンドウィンドウで今コピーしてきたフォルダへ移動

nrf_sniffer_ble.sh --exrcap-interfaces

を実行。うまく通らない。

エラー文と中身から、パスの問題かな・・・？

./nrf_sniffer_ble.sh --extcap-interfaces

で動いた。

refresh interfaceをすると

インターフェースがでてきた。あとちょっとや！

プロファイルの設定

ここから開いたフォルダにあるprofiles配下に

Profile_nRF_Sniffer_Bluetooth_LEフォルダをそのままぶちこむ

configuration profileから

さっき追加したやつを選んでOK

これで準備はととのったっぽい

近くにBLE通信するデバイス達（セントラル＋ペリフェラル）を置いて・・・

start!

おおおーー見えた！

満足したので中身をがっつり確認するのはまた今度。