Azure Logic Appsで、CSVファイルをSQL Databaseに取り込む方法
手順
- CSVファイルを配置するためのストレージアカウントを作成
- SQL Databaseからストレージアカウントにアクセスするために、SASを生成
下記の通り設定 ※有効期限は任意で、期限が切れたら再発行が必要
- コンテナ―を作成して、CSVファイルを配置
- コンテナ―のプロパティでURLを確認
- SQL Databaseにクエリエディター等でログイン
- マスターキーを作成 ※既に作成済であれば、作成不要
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '適当な文字列' Blob Storageにアクセスするためのクレデンシャルを作成
CREATE DATABASE SCOPED CREDENTIAL 任意の名前 WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = '手順2で生成したSASトークン';※クレデンシャルを更新する場合
ALTER DATABASE SCOPED CREDENTIAL 更新対象の名前 WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = '手順2で生成したSASトークン';Blobへの接続を作成
CREATE EXTERNAL DATA SOURCE 任意の名前 WITH ( TYPE = BLOB_STORAGE, LOCATION = '手順4のURL', CREDENTIAL = 手順7で作成したクレデンシャル名 );- ストアドプロシージャを作成 ※CSVファイル(UTF-8)のデータをテーブルに追記する例
- Logic Appsで「ストアドプロシージャを実行する」アクションを追加
- データベースへの接続設定を作成 ※既に作成済であれば、作成不要
- プロシージャ名に、手順9で作成したストアドプロシージャを選択
Amazon RDSについて
概要
Aurora
Standard
- 読み取りと書き込みのI/O操作に対する追加料金が発生する構成
- I/Oの頻度が低い場合(I/O料金がAuroraの利用料の25%未満の場合)に採用
I/O最適化
- 読み取りと書き込みのI/O操作に対する追加料金が発生しない構成
- I/Oの頻度が高い場合(I/O料金がAuroraの利用料の25%以上の場合)に採用
Aurora Serverless
- Amazon AuroraにおいてオンデマンドのAuto Scaling設定が行えるデータベース
- アプリケーションニーズに応じて自動的に起動・停止が可能で、データベース容量を管理することなく、スケールアップ・スケールダウンが可能
- あらかじめスペックを設定せず、指定した範囲内でスペックが自動的に上下する
- 指定する範囲は、Aurora Capacity Unit (ACU)という単位で0.5~128で設定可能
- 1ACUは2GBのメモリと、対応するコンピューティングとネットワーキングを提供
RDS
- DBエンジンが以下から選択可能
- 最新バージョンが使用可能
- Auroraはあくまで互換のため、最新バージョンに対応するまでに期間が空く
- DBインスタンスとストレージがセット
- Auroraはそれぞれ独立
Aurora、Aurora Serverless、RDSの比較
AuroraとRDSで、Auroraの方が安くなるケース
- 障害発生後、最大10分間DBにアクセス出来なくても問題ない場合
- 障害発生時の自動復旧が、RDSの場合はマルチAZ構成にする必要があるが、Auroraの場合はレプリカを作成しなくてもよいため
ユースケース
AuroraとRDSでの比較
Aurora
- 「MySQL」、「PostgreSQL」いずれかのDBエンジンを使用したい場合
- Auroraで対応しているバージョンの使用で問題ない場合
- より高い耐障害性や性能が必要な場合
RDS
- 「MariaDB」、「Oracle」、「SQL Server」いずれかのDBエンジンを使用したい場合
- Auroraで対応していない最新のバージョンを使用したい場合
AuroraとAurora Serverlessでの比較
Aurora
- 必要なDBのスペックがある程度分かる
- 使用負荷が急激に増加する時間帯がない、または急激に増加する時間帯が明確
Aurora Serverless
- 平常時は使用負荷が軽い
- 予測不能な使用負荷が急激に増加する時間帯があり、その時間が短い
- 例）大雨が降り天気予報のサイトに普段より急激にアクセスが集中する
- 必要なDBのスペックが不明
Amazon Redshiftについて
ノードタイプについて
| ノードタイプ | 概要 |
|---|---|
| DC2インスタンス | 各コンピューティングノードが個別のSSDストレージを持つタイプ。 データ処理の独立性が高まりさらなるパフォーマンス向上につながる。 |
| DS2インスタンス | 各コンピューティングノードが個別のHDDストレージを持つタイプ。 速度面ではSSDを採用しているDC2インスタンスに及ばないものの、より大容量で構築することが可能。 |
| RA3インスタンス | コンピューティングとストレージがそれぞれ独立しているタイプ。 各ノードは個別のストレージを持たない代わりに、RMS（Redshift Managed Storage）を共有利用する。RMSは、「Amazon S3」のデータ領域を内部的に利用。 ノードが軽量なため拡張性に優れ、必要な処理能力に応じたスケールアウトが容易。 アクセス頻度が高いデータは「AQUA」と呼ばれるキャッシュ領域で高速処理される。 |
RA3インスタンスを利用するメリット
- コンピューティングとストレージを個別に拡張出来るため、必要な部分のみ拡張をすることで、料金削減につながる。
- その他のインスタンスタイプだとコンピューティングとストレージがセットになっているため、コンピューティングのみ拡張をしたい場合でも、ストレージも拡張する必要があった。
- DC2インスタンスと比較して8倍以上のストレージ容量を実現している。
- DS2インスタンスと比較して最大2倍のパフォーマンスとストレージ容量を実現している。
同時実行スケーリングについて
- 同時実行スケーリング機能を使用すると、一貫した高速のクエリパフォーマンスで、数千の同時ユーザーと同時クエリをサポートできる。
- 書き込みの同時実行スケーリングに対応しているのは、RA3インスタンスのみ。
- Redshift Serverlessでは同時実行スケーリングは標準で搭載されている。
- 料金は、1日あたり最長1時間無料。
AWS ソリューション「AWS でのワークロード検出」について
概要
AWSが用意しているCloudFormationのテンプレートを元に以下構成のWEBサイトを構築することで、現状のAWSの構成が確認出来るようになる。
料金
※バージニア北部リージョンで単一構成の場合
構築手順
- ワークロード検出のページから「AWSコンソールで起動する」ボタンを押下する。
- CloudFormationの作成をする。
- メールが届いているため、メールの情報を元にログインする。
- 「Import」ボタンを押下する。
- AWSのアカウント情報を入力後、「Add」ボタンを押下して「Import」ボタンを押下する。
- 赤枠で囲った2つのボタンを押下して、CloudFormationのテンプレートファイルをダウンロードする。
- 6でダウンロードしたファイルを用いてワークロード検出に必要なIAMロール等を作成する。
- 「Import」ボタンを押下する。
- 作成したい構成図のリソースを選択して、「Add to diagram」ボタンを押下する。
- 構成図が作成される。
以下の形式で出力も出来る。
備考
- CloudFormationのスタックの削除をすることで、構築した環境は全て削除出来る。
- NatGateway等の停止が出来ず、存在するだけで料金がかかるものがあるため、利用しない際に料金がかからないようにするには、削除する必要がある。
GCE内のログファイルを監視してアラート通知をする方法
概要
以下の流れでアラート通知を行う
- GCE内のログファイルをCloud Loggingに送信する。
- Cloud Monitoringで監視して特定の文字列を検出したらアラート通知をする。
設定手順
GCE側で設定すること
- こちらに従って、Ops エージェントを導入する。
- Ops エージェントの設定を変更する。
C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yamlにログをCloud Loggingに送信する設定を追加する。※- https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent/configuration?hl=ja
- 設定を反映させるため、以下コマンドでOps エージェントを再起動する。
Restart-Service google-cloud-ops-agent -Force
※ 設定例
logging:
receivers:
任意の名前1:
type: files
include_paths: [Cloud Loggingに送信対象のログファイルのパス]
service:
pipelines:
任意の名前2:
receivers:
- 任意の名前1
Google Cloud側で設定すること
Cloud Loggingのアラート作成を選択
アラートポリシーを作成
| 項目名 | 設定内容 |
|---|---|
| Alert details | アラートの名称等の設定 |
| Choose logs to include in the alert | アラート対象とするログの抽出設定 |
| Set notification frequency and autoclose duration | 通知間隔やインシデントの自動クローズまでの期間の設定 |
| Who should be notified? | EmailやSlack等の通知先の設定 |
IN句に複数カラム指定するSQLをActive Recordで表現する方法
概要
Ruby on RailsのActive Recordで、IN句に複数カラム指定するSQLを表現する方法。
SQL例
SELECT * FROM test_table WHERE (test_col1, test_col2) IN (('test1', 'test2'), ('test3', 'test4'));
Active Recordで表現する方法
test_arrays = [ ['test1', 'test2'], ['test3', 'test4'] ] test1 = test_arrays.map do | array | TestTable.where( test_col1: array[0], test_col2: array[1] ) end test2 = test1.reduce{|sum, v| sum.or(v)}
こちらの短縮版は、以下の通りになる。
test_arrays = [ ['test1', 'test2'], ['test3', 'test4'] ] test1 = test_arrays.map do | array | TestTable.where( test_col1: array[0], test_col2: array[1] ) end.reduce(&:or)
