[Azure] Event Hubs / Stream Analyticsを使ってみた
Event Hubの作成
Event Hubの作成手順はざっくり以下。
- Event Hubs名前空間を作成する。Event Hubに接続する際の接続文字列は名前空間で提供される。
- 作成した名前空間にて、Event Hubを作成する。ここでパーティション数、メッセージの保持期間が設定できる。
Event Hubにイベントを送信する際は送信デバイス側で以下を指定します。
- 名前空間レベルの接続文字列
- Event Hub名
Stream Analyticsの作成
Stream Analytics Jobを作成します。そのあとInput、Output、Query等の設定を行います。
最初Input、Outputの設定だけ実施し、データがOutputに流れませんでしたが、Queryの内容を今回定義したInput、Outputの名前に修正することで解決しました。データを加工しない場合もQueryを編集する必要があるのですね。
実際にデータを流してみる
以下で紹介されているサンプルプログラムを使ってPCからデータをEventHubに流しました。
リアルタイム イベントのデータの異常を視覚化する - Azure Event Hubs | Microsoft Docs
データの流れは以下です。今回はデータ加工は一切していません。
PC → Event Hub → Stream Analytics →SQL Database
Stream AnalyticsからSQL Databaseに出力される際に、JSONデータのメンバをDBのカラムに対応付けしてくれます。そのためそれに応じたテーブル定義を作成しておく必要があります。
なお、投入したJSONのテストデータに加えてEventHubで追加されるメンバがあるようです。（以下図、右3カラム）
プロマネが意識するべきポイント（個人的見解）
はじめに
今までいろいろ考えながらプロマネをやってきて、色々思うところがあるので整理します。プロマネの仕事は仕事の具体的な内容より、何を意識すべきかが重要だと思っており、それをまとめました。プロマネだけでなく一般的なマネジメントにも通用することかと思います。
プロマネの仕事の本質は考えること、判断すること
管理「作業」がプロマネの仕事ではない。管理作業等の「手段」を通じて考えたり判断することがプロマネの仕事であり、そこを履き違えたプロマネはマネージャーではない。
目的はなにか？を常に意識する（させる）
一番大事なのはプロジェクトの目的。これはプロマネもプロジェクトメンバーも顧客も含めて、意識することが大事です。皆に意識させるのはプロマネの仕事です。プロジェクトの目的が意識できていれば、様々な状況でプロジェクトメンバーが正しい方向に判断してくれるようになり、自律的なチームになります。
メンバーを信頼する（かどうかを判断する）
プロマネはメンバーを信頼しなければいけません。もしくは、メンバーが信頼に足るかどうか判断をしなければいけません。メンバーを信頼しなければ、プロマネが仕事を抱えてしまうことになります。また、メンバーが信頼できるかどうかを考えることを怠った場合、メンバーがポンコツであることに気づかずに難しい仕事を振ってしまうことになります。
プロマネの責任
どんなに顧客がモンスターでも、どんなにプロジェクトメンバーがポンコツでも、プロジェクトを成功させることがプロマネの責任です。これを頭でも体でも理解できていないと、プロマネはできないです。（プロマネ業務をしている ≠ プロマネの責任を果たしている です）。プロマネはプロジェクトを成功させる、という目的に対しては手段を選んではいけません。プロジェクトメンバーだけで解決できないのであれば、社内・社外のリソースの活用、経営層レベルへのエスカレーションなど、プロマネはありとあらゆる手を使ってでもプロジェクトを成功させる必要があるのです。
ひとさじの熱い想い
冷静なマネジメントだけではプロジェクトは前に進まないことがある。リーダーとしてメンバーを動かす熱い想いも必要です。
SQL Server のTCP/IPプロトコル構成の既定値がエディションによって異なる
はじめに
- SQL Server 2017で確認したことです
- 意外な仕様だったのでメモしておきます
きっかけ
SQL Server 2017 Developer Editionをインストールし別ホストから接続確認をしたところ、接続不可でした。SQL Server構成マネージャでネットワークプロトコルの設定を確認したところ、TCP/IPが「無効」になっていました。この前インストールしたとき（Enterprise Edition）はもともと「有効」で別ホストからの接続はできたので、「あれ？」と思い調べてみました。
TCP/IPプロトコル構成の既定値について
公開情報がすぐみつかりました。既定値はエディション毎に異なるようで、以下の通りです。
エディション 共有メモリ TCP/IP 名前付きパイプ Enterprise 有効 有効 ネットワーク接続に対して無効です。 Standard 有効 有効 ネットワーク接続に対して無効です。 Web 有効 有効 ネットワーク接続に対して無効です。 Developer 有効 Disabled ネットワーク接続に対して無効です。
SQL Server の既定のネットワーク プロトコル構成 | Microsoft Docs
DeveloperエディションのTCP/IPの既定は「無効」というところがポイントです。Developerエディションは開発用途に限定されるというライセンスの制約があるだけでEnterpriseエディションと同じものだと思っていましたが、このような差はあるのですね。
データベースでSSDを採用するときの設計メモ
はじめに
データベースのストレージにHDDではなくSSDを採用するシステムが増えてきていると思いますが、データベース設計をするにあたりHDDの場合と何が違うのか、検討したことをメモで残しておきます。SQL Serverの言葉で書いていますが、考えはどのRDBMSでも同じかと思います。
ファイル配置
HDDの場合、データファイルとトランザクションログファイルは別ディスクに配置する、というのがファイル配置設計の鉄則でした。これは、データベースにおいて重要な2種類のファイルのIOを分散するという理由もありますが、ランダムアクセス（データファイル）とシーケンシャルなアクセス（トランザクションログファイル）を分ける、という理由が大きいかと思います。HDDの物理的な特性上、これらのアクセスが混在するとHDDが得意なシーケンシャルなアクセスが性能劣化するからです。
SSDの場合、データファイルとトランザクションログファイルを別ドライブに配置するということは必須ではないと思います。SSDはHDDのようにシーケンシャルなアクセスが得意というわけではありません。というよりもシーケンシャルなアクセスとランダムアクセスで性能はあまり変わりません。そのためデータファイルとトランザクションログファイルを同ドライブに配置しても大きな性能劣化には繋がりません。もちろん分けた方がIOは分散するので効果はあると思いますが、HDDで分けていたほどのプラス効果は出ないということです。
データ断片化の影響
SSDの場合、断片化の性能影響が緩和されると思います。断片化はページの充填率であるページ密度が低い状況、またはページの論理的な並び順と物理的な並び順が一致しない状況（論理スキャンフラグメンテーション）のことを言います。このうち後者、論理スキャンフラグメンテーショについてはHDDでは性能影響がありますが、SSDではほぼ影響は無いと言えると思います。理由は前述した通りで、SSDはHDDと違いシーケンシャルなアクセスとランダムアクセスで性能はあまり変わらないからです。
SQL Server データ暗号化（TDE）有効化時の注意すべき挙動
前提
- SQL Server 2017
- 暗号化方式はTransparent Data Encryption (TDE)
データ暗号化（TDE）時の注意すべき挙動
データ暗号化（TDE）は以下手順で実施します。ここは特に問題なし。
透過的なデータ暗号化 (TDE) | Microsoft Docs
USE master;
GO CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
go
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';
go
USE AdventureWorks2012;
GO CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128 ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO
ALTER DATABASE AdventureWorks2012 SET ENCRYPTION ON;
GO
この最後の 「ALTER DATABASE AdventureWorks2012 SET ENCRYPTION ON;」で暗号化を有効化しているのですが、このコマンドは暗号化の完了と非同期であり、コマンド完了＝暗号化完了ではないようです。暗号化の完了はステータスから判断する必要がありますので注意が必要です。
データ暗号化（TDE）完了の確認方法
以下SQLにて暗号化ステータスを確認できます。
SELECT encryption_state FROM sys.dm_database_encryption_keys
WHERE database_id = 'データベースID
暗号化の有効化時のステータスの遷移は以下のようになります。
1：暗号化されていない
↓
暗号化の有効化
↓
2：暗号化中
↓
3：暗号化 ※これで暗号化が完了
ちなみに暗号化の無効化時のステータスの遷移は以下のようになります。
ステータスの遷移は以下のようになります。
3：暗号化
↓
暗号化の無効化
↓
5：暗号化解除中
↓
1：暗号化されていない ※これで暗号化の無効化が完了
sys.dm_database_encryption_keysシステム動的管理ビューの詳細は以下参照。
sys.dm_database_encryption_keys (TRANSACT-SQL) | Microsoft Docs
AlwaysOn 可用性グループの非同期ノード停止時のログ切り捨て動作について
前提
- SQL Server 2017
はじめに
可用性グループの可用性モードには、同期コミットモード、非同期コミットモードがあります。同期コミットモードのレプリカが1台でも停止した際にはプライマリデータベースのトランザクションログの切り捨てが実施できなくなります。これは同期コミットモードでは当然かと思います。非同期コミットモードのレプリカが停止した場合はどうなのか？検証してみました。
結果
同期コミットモードのレプリカ停止時と同様、非同期コミットモードのレプリカ停止時もプライマリデータベースのトランザクションログの切り捨てが実施できなくなります。非同期モードではログの適用まで同期はしませんが、ログの送信ができなければログを切り捨ててよいことにはならないようですね。
よって非同期コミットモードのレプリカにおいても障害時には、障害復旧までの時間とトランザクションログ領域の余裕から対応を判断する必要があります。トランザクションログ切り捨てを優先する必要があれば、障害レプリカを可用性グループから一旦削除するという対応を考える必要があります。
WSFCの記憶域追加時のメモ
前提
- Windows Server 2012 R2
- WSFC構築時に少しハマったのでメモ
やったこと
クラスタを作成する際または作成後に、クラスタリソースとして記憶域（ディスク）の追加を行うと思いますが、その際に認識されるはずのディスクがクラスタのディスクとして認識されず追加ができない事象があり一瞬ハマりました。
原因は当該ディスクに「パーティションをアクティブとしてマーク｣が設定されていたことでした。ディスクの管理画面にてディスクに対して右クリックした際に誤って「パーティションをアクティブとしてマーク」を押してしまったものと思われます。これを「非アクティブ」に戻すにはGUIでは不可でして、diskpartコマンドを使用す必要があります。
手順の詳細は以下。
｢パーティションをアクティブとしてマーク｣を間違えて設定した場合の解除方法 - FOR THE SOPHISTICATED PEOPLE
１．コマンドプロントを起動
２．「diskpart」と入力する。
３．「list disk」と入力し解除したいパーティションのドライブの番号を調べる。
４．「select disk 0」（0は3.で調べたドライブ名）と入力し、フォーカスをドライブに移動。
５．「list partition」と入力し解除したいパーティションのパーティション番号を調べる。
６．「select partition 1」(0は5.で調べたパーティション番号) と入力しフォーカスをパーティションに移動。
７．「inactive」と入力すると、アクティブが解除される。
(「active」と入力すれば、アクティブに設定される。)
８．「exit」を2回入力しコマンドプロントを閉じる。
上記手順により「非アクティブ」に戻した後は想定通りクラスタの記憶域として認識されたため、ディスクをクラスタに登録することができました。
