アジャイルソフトウェア開発の奥義 第2版
「ソフトウェア設計」に関する書籍としていい感じだなと思った。
アジャイルソフトウェア開発の奥義 第2版
オブジェクト指向開発の神髄と匠の技
SBクリエイティブ:アジャイルソフトウェア開発の奥義 第2版
投資家、起業家、企業経営者の話
■IVSウィンターワークショップ2013 Session 5
テーマ: 「人生は挑戦だ!」
(スピーカー)
株式会社ディー・エヌ・エー 顧問 川田尚吾 氏
株式会社gumi 代表取締役社長 國光宏尚 氏
KLab株式会社 代表取締役社長 真田哲弥 氏
ヤフー株式会社 執行役員 小澤隆生 氏
(モデレーター)
インフィニティ・ベンチャーズLLP 共同代表パートナー 小野裕史
vimeo.com
■べンチャー・キャピタル進化論~経営者と投資家の付き合い方
川田尚吾氏
松山太河氏
赤浦徹氏
渡辺洋行氏
G1ベンチャー2015
www.youtube.com
■プロフェッショナル 仕事の流儀
「ベンチャー企業経営者 南場智子の仕事 仕事でこそ、人は育つ」
www.youtube.com
SQL Server 2016 データ暗号化
SQL Server 2016 の新機能「Always Encrypted」。
Always Encrypted (データベース エンジン) | Microsoft Docs
以下サイトで、どんなものか確認してみる。
SQL Server 2016 CTP 2.0 の Always Encrypted を使ってみる at SE の雑記
ということらしい。「Always Encrypted」の動作については、また後ほど確認してみるとして。
今のところは、いろいろと検討した結果、管理者側の機能としては、
顧客の「システム担当」が、対称キー作成時のパスワードを
ユーザー情報の登録/更新/参照の際(対称キーOpenの際)に入力した時に、
・ユーザー情報を暗号化して登録(更新)できる
・ユーザー情報を復号化して参照できる
といった動作にしていくことを予定。
なので「Always Encrypted」を使用しない方法でやってみる。
【1】対称キーの作成(アルゴリズムは AES_256 を指定)
CREATE SYMMETRIC KEY Beck_Sym_Key WITH ALGORITHM = AES_256 ENCRYPTION BY PASSWORD = '[SymKeyPassword]' go
【2】登録時の操作(暗号化)
(例)MST_USERテーブル(CREATE文)
暗号化する項目は[varbinary](max)型。
CREATE TABLE [dbo].[MST_USER]( [SystemUserID] [uniqueidentifier] NOT NULL, [UserID] [varbinary](max) NOT NULL, [LoginID] [varbinary](max) NOT NULL, [Password] [varbinary](max) NOT NULL, [LastName] [varbinary](max) NOT NULL, [FirstName] [varbinary](max) NOT NULL, [LastNameKana] [varbinary](max) NOT NULL, [FirstNameKana] [varbinary](max) NOT NULL, [MailAddress1] [varbinary](max) NOT NULL, [MailAddress2] [varbinary](max) NULL, CONSTRAINT [PK_MST_USER] PRIMARY KEY CLUSTERED ( [SystemUserID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO
(1)対称キーをオープンする。対称キーの GUID を Key_GUID 関数で取得して、
EncryptByKeyでデータを暗号化して INSERT する。
OPEN SYMMETRIC KEY Beck_Sym_Key DECRYPTION BY PASSWORD = '[SymKeyPassword]' go DECLARE @kGuid UNIQUEIDENTIFIER SET @kGuid = Key_GUID('Beck_Sym_Key') INSERT INTO MST_USER ( [SystemUserID], [UserID], [LoginID], [Password], [LastName], [FirstName], [LastNameKana], [FirstNameKana], [MailAddress1], [MailAddress2] )VALUES( NEWID(), EncryptByKey(@kGuid, "[UserID]", EncryptByKey(@kGuid, "[LoginID]", EncryptByKey(@kGuid, "[Password]", EncryptByKey(@kGuid, "[LastName]", EncryptByKey(@kGuid, "[FirstName]", EncryptByKey(@kGuid, "[LastNameKana]", EncryptByKey(@kGuid, "[FirstNameKana]", EncryptByKey(@kGuid, "[MailAddress1]", EncryptByKey(@kGuid, "[MailAddress2]" )
(2)対称キーの CLOSE
CLOSE SYMMETRIC KEY Beck_Sym_Key go
(参考)SELECT文を実行するとデータが暗号化されていることを確認できる。
SELECT * FROM MST_USER
【3】参照時の操作(復号化)
(1)SELECT文を実行(DecryptByKey で復号化)
対称キーをOPENして、SELECT文を実行。DecryptByKeyでデータを復号化する。
OPEN SYMMETRIC KEY Beck_Sym_Key DECRYPTION BY PASSWORD = '[SymKeyPassword]' SELECT TOP 1000 [SystemUserID] ,CONVERT(varchar, DecryptByKey([UserID])) AS [UserID] ,CONVERT(varchar, DecryptByKey([LoginID])) AS [LoginID] ,CONVERT(varchar, DecryptByKey([Password])) AS [Password] ,CONVERT(varchar, DecryptByKey([LastName])) AS [LastName] ,CONVERT(varchar, DecryptByKey([FirstName])) AS [FirstName] ,CONVERT(varchar, DecryptByKey([LastNameKana])) AS [LastNameKana] ,CONVERT(varchar, DecryptByKey([FirstNameKana])) AS [FirstNameKana] ,CONVERT(varchar, DecryptByKey([MailAddress1])) AS [MailAddress1] ,CONVERT(varchar, DecryptByKey([MailAddress2])) AS [MailAddress2] FROM [ProjectManagementSystem].[dbo].[MST_USER]
(2)対称キーの CLOSE
CLOSE SYMMETRIC KEY Beck_Sym_Key
(参考)SELECT文を実行して復号化されたデータを参照。
※対称キーをDROPする場合
DROP SYMMETRIC KEY Beck_Sym_Key
【4】ユーザ登録を行うプロシージャのサンプル
CREATE PROCEDURE [dbo].[RegistUser] @SymKeyPassword varchar(250), @UserID varchar(250), @LoginID varchar(250) , @Password varchar(max) , @LastName varchar(max) , @FirstName varchar(max) , @LastNameKana varchar(max) , @FirstNameKana varchar(max) , @MailAddress1 varchar(max), @MailAddress2 varchar(max) AS BEGIN DECLARE @OpenCmd nvarchar(MAX) SET @OpenCmd =N'OPEN SYMMETRIC KEY Beck_Sym_Key DECRYPTION BY PASSWORD = ''' + @SymKeyPassword + ''' ' EXECUTE sp_ExecuteSql @OpenCmd DECLARE @kGuid UNIQUEIDENTIFIER SET @kGuid = Key_GUID('Beck_Sym_Key') INSERT INTO MST_USER ( [SystemUserID], [UserID], [LoginID], [Password], [LastName], [FirstName], [LastNameKana], [FirstNameKana], [MailAddress1], [MailAddress2] )VALUES( NEWID(), EncryptByKey(@kGuid, @UserID), EncryptByKey(@kGuid, @LoginID), EncryptByKey(@kGuid, @Password), EncryptByKey(@kGuid, @LastName), EncryptByKey(@kGuid, @FirstName), EncryptByKey(@kGuid, @LastNameKana), EncryptByKey(@kGuid, @FirstNameKana), EncryptByKey(@kGuid, @MailAddress1), EncryptByKey(@kGuid, @MailAddress2) ) CLOSE SYMMETRIC KEY Beck_Sym_Key END
Visual Studio 2015 Professional VB.NET 単体テストの作成
Visual Studio 2015 Professional VB.NET(以下、VB)にて、MSTestを利用した単体テストの自動化を試しています。ユニットテスト・フレームワークはたくさんありますが、VisualStudio標準の「MSTest」から使ってみようというところです。
手順を確認した際に、VBにおいてコードエディタ上のコンテキストメニューから「単体テストの作成」が行えない現象が発生する場合がありました(※VBの単体テストプロジェクトを手動で作成する方法や、C# の場合には問題なく行えました)。 現時点で、他の端末での動作等は未確認のため、端末依存の問題であるかどうか不明で、また、設定が不足している、VisualStudioの不具合とも断定できない状況ではあります。
ただ、VBにおいても、コードエディタ上で右クリックから単体テストの作成を行えた方が便利と思い、コンテキストメニューから「単体テストの作成」が行えない現象を回避する方法を見つけましたので、記載しておきます。
■前提
前提としては、コードエディタ上のコンテキストメニューに「単体テストの作成」を表示する設定が行われていることです。まずは、「単体テストの作成」をコンテキストメニューに表示する設定を行う必要があります。
以下のサイトはVisualStudio2012の手順にはなりますが、参考になりました。
VisualStudio2015でも同様の手順で設定が行えます。
すがろぐ – visualization
■手順(例)
VBでコードエディタ上のコンテキストメニューから「単体テストの作成」を行うための操作
(2) VBのクラスライブラリを選択します。OKボタンを押下します。
(4) ソリューションエクスプローラーで、ソリューションを右クリック→[追加]→[新しいプロジェクト]を選択します。
(5) C#のクラスライブラリを選択します。OKボタンを押下します。
(8) (C#)以下のエラー画面が表示されます。[OK]ボタンを押下します。
「RDBMS」と「NoSQL」の比較
【1】「RDBMS」- ACID特性
RDBMS(リレーショナルデータベース管理システム)は、ACID特性という概念に基づいて設計されている。
ACID特性とは、トランザクション処理において必要とされる4つの要素、Atomicity(原子性)、Consistency(一貫性)、Isolation(独立性)、Durability(永続性)を頭字語で表したもの。
■ACID特性
要素 | 説明 |
---|---|
A:原子性 (Atomicity) |
トランザクションに含まれるタスクが全て実行されるか、あるいは全く実行されないことを保証する性質。 |
C:一貫性 (Consistency) |
トランザクション開始と終了時に予め与えられた整合性を満たすことを保証する性質 。 Consistencyは日本語では「一貫性」あるいは「整合性」とも呼ばれる。 |
I:独立性 (Isolation) |
トランザクション中に行われる操作の過程が他の操作から隠蔽されることを指し、日本語では分離性、独立性または隔離性ともいう。より形式的には、独立性とはトランザクション履歴が直列化されていることと言える。この性質と性能はトレードオフの関係にあるため、一般的にはこの性質の一部を緩和して実装される場合が多い。 |
D:永続性 (Durability) |
トランザクション操作の完了通知をユーザが受けた時点で、その操作は永続的となり、結果が失われないことを指す。 |
【2】「NoSQL」 - BASE特性とCAP定理
NoSQLはBASE特性という概念に基づいて設計されている。
クラウド、ビッグデータ処理において、中心的な概念となるのが「BASE特性」と「CAP定理」。
BASE特性とは、「基本的には常に利用可能で、常に整合性を保っている必要はなく、一時的に一貫性のない状態を許容して、結果的には整合性が取れている状態に至る」という特性。
インクトミの創業者、カリフォルニア大学バークレー校の計算機科学の教授エリック・ブリュワー氏が、
「ACID」とは対照的に、可用性や性能を重視した特性を持つ分散システムの特性を「BASE」という文字で表した。
CAP定理はブリュワーの定理とも呼ばれる。分散コンピュータシステムのマシン間の情報複製に関する定理。
ウェブサービスを想定して作られた定理。
2000年にエリック・ブリュワー氏によって提案され、その後、2002年にマサチューセッツ工科大学のセス・ギルバート氏、ナンシー・リンチ氏によって証明されており、定理として確立されている。(CAP定理 - Wikipedia)
■NoSQLのデータモデル
①Key-Valueストア | ②Key-Valueストア | ③ドキュメントDB | |
---|---|---|---|
データ モデル |
Key-Value | カラム指向(ワイドカラム) | ドキュメント指向(JSON) |
特徴 | ・データアクセスが高速 ・小さい多数のデータの 蓄積が得意 |
・一部のものは スキーマ定義が必要 ・カラム指定での範囲検索、 集計処理が得意 |
・ドキュメント毎に 異なるデータ構造を持てる ・属性に対する検索・集計が可能 |
活用例 | ・キャッシュサーバ ・ログ蓄積 |
・大規模データ処理 ・ログ蓄積 ・ログ分析 |
・ログ分析 ・Webシステム ・オンラインゲーム |
OSS例 | ・memcached ・Redis |
・Cassandra ・HBase |
・MongoDB |
■BASE特性
要素 | 説明 |
---|---|
(BA) Basically Available |
基本的にいつでも利用できる。 |
(S) Soft-State |
常に整合性を保っている必要はない。 |
(E) Eventual Consistency |
結果的には整合性が保証される。 |
NoSQLの特徴を表している概念として覚えておきたいところ。上記3つの工夫をして、性能をスケールさせていることにより、ビッグデータを扱えるようになっている。
■CAP定理
定義:ノード間のデータ複製において、同時に次の3つの保証を提供することはできない。
保証 | 説明 |
---|---|
C:一貫性 (Consistency) |
全てのノードで同時に同じデータが見える。 |
A:可用性 (Availability) |
単一障害など一部のノードで障害が起きても処理の継続性が失われない。 |
P:分断耐性 (Partition-tolerance) |
任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。 |
CAP定理によると、
分散システムは「C」「A」「P」の3つの保証のうち、同時に2つの保証を満たすことはできるが、
同時に3つの保証すべてを満たすことはできないとされている。
CAP定理により、
データベース管理システムは「CA型」「CP型」「AP型」のいずれかのタイプに分類できる。
RDBMSは「CA型」、NoSQLは主に「CP型」または「AP型」となる。
■CAP定理によってデータベース管理システムのタイプを分類
タイプ | 説明 |
---|---|
CA型 (C:一貫性とA:可用性を重視) |
データはいつでも利用可能で一貫している。 →単一データベースサーバ |
CP型 (C:一貫性とP:分断耐性を重視) |
データを分散しつつも整合性を保持する。 →整合性保持のため、複製中は全てのノードでデータ更新されるまで ロックをかけて不整合を阻止する。 →ロックがかかっている最中はAvailableではない。 |
AP型 (A:可用性とP:分断耐性を重視) |
データは分散され、いつでもデータにアクセスできる →データ複製中は不整合な状態になり得る。 →Cはある程度妥協する。(Eventual consistency) |
■各タイプ別にデータベース管理システムを分類
タイプ | データベース管理システム |
---|---|
CA型 (C:一貫性とA:可用性を重視) |
リレーショナル型:Oracle、MySQL、PostgreSQL、SQLServer カラム指向:Vertica |
CP型 (C:一貫性とP:分断耐性を重視) |
Key-Value:Redis、memcached、Scalaris カラム指向:BigTable、HBase ドキュメント指向:MongoDB |
AP型 (A:可用性とP:分断耐性を重視) |
Key-Value:TokyoTyrant/Cabinet、Dynamo、Voldemort カラム指向:Cassandra ドキュメント指向:SimpleDB、CouchDB、Riak |
(参考文献)
『RDB技術者のためのNoSQLガイド』秀和システム
(参考URL)
RDBMSとNoSQLの周辺技術や考え方の整理
http://tanakakns.hatenablog.com/entry/20140502/1399019336
NoSQL、CAP定理、BASE、Eventual Consistencyについて深く考えてみた
http://shunichi-arai.blogspot.jp/2012/09/nosqlcapbaseeventual-consistency.html
IoTに適したNoSQL・分散Key-Valueストア
https://thinkit.co.jp/story/2014/09/25/5280?page=0%2C1
Visual Guide to NoSQL Systems
http://blog.nahurst.com/visual-guide-to-nosql-systems
CAP定理-wikipedia
https://ja.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
NoSQL登場の背景、CAP定理、データモデルの分類
http://www.publickey1.jp/blog/10/nosqlcap.html
12年後のCAP定理: "法則"はどのように変わったか
https://www.infoq.com/jp/articles/cap-twelve-years-later-how-the-rules-have-changed
CAP定理
http://namihira.hatenablog.com/entry/2013/12/19/233853
クラウドでの新しいACID、そしてBASEトランザクションとCAP定理
http://jyukutyo.hatenablog.com/entry/20090430/1241174854