野良エンジニアの足跡 -13ページ目

SEA/J 基礎(CSBM:Certified Security Basic Master)

こんにちは、nagino です。

昨日 SEA/J の情報セキュリティ技術認定 基礎コース(CSBM)を受験してきました。

結果は 90% と余裕を持って合格でした。


この SEA/J の資格は、受験生にとってはとにかく市販書籍が無いことが特徴とも言えるほど、情報が少ないです。

公開されている情報は、学習範囲(出題範囲)の項目のみです。

http://www.sea-j.net/curriculum/basic.html

これは、SEA/J が提供している研修が主で、試験はあくまでその結果を認定するためのものと位置づけられているようですので、納得できるところではあります。

ですが、試験のみの受験が可能であり、その際に難易度の目安が無いというのは非常に厄介ですので、簡単に紹介しておきたいと思います。


試験の形式は 60 分 80 問と、比較的短時間に多数の問題を回答する必要があります。

しかし、全て 4 つの選択しからの択一であり、問題文も 1~3 行程度と非常に短くなっています。

半数程度は一読すれば即回答できる程度のシンプルな問題でした。

合格ラインは 70% ですので、苦手分野などは捨てても十分合格できます。


試験の内容は、技術のみならず運用や概念、制度といった方面も出題されます。

技術面は、各プロトコルの詳細(通信の詳細な流れやパケットの構造など)はほとんど出ません。

電子証明書・PKI と IDS・IPS だけは出題数も多く(15 ~ 20 問程度?)、やや細かい内容も出題されますので、その箇所のみはある程度勉強する必要があります。

ポート番号なども HTTPS などの基本的なもののみ押さえれば十分なようです。

一方、制度などのほうでは ISO/IEC 27001 といった具体的な番号まで含めて出題(2 ~ 3 問程度?)されますので、それなりに抑える必要がありました。


分野としては、先に記載した学習範囲にあるとおり 16 分野に分かれており、それぞれから 3 ~ 7 問ずつ出題されるようですので、広く浅く習得しておくことが必要になります。

情報処理技術者試験の情報セキュリティスペシャリストと範囲が非常に似通っていますが、難易度は大きく異なりますので、情報セキュリティスペシャリストの対策本(問題集ではなく教科書系)をざっと斜め読みすれば十分という印象でした。


なお、対称鍵暗号が「対象」鍵暗号となっていたり、助詞(~の、~に)が不適切で日本語として文意が通らない選択肢など、質の悪い問題が数問散見されました。

そのようなケースでは、出題意図や消去法による対応が必要になりますので、満点合格は難しいかもしれません。


総じて、入社 2 年目の技術者であれば取れるかなという印象でした。

逆に 2 年目でこの程度が取れないと、技術者としては厳しいと思われます。


具体的な問題などは受験規定上記載できませんが、難易度の目安にでもなれば幸いです。


追加コスト 0 で行う SQL Server のパフォーマンス改善・ボトルネック解消 その0

こんにちは、nagino です。


記事をまとめようとしているとなかなか書けずに時間だけ過ぎていくので、しばらくタイトルのネタで雑多に書き散らし、最後にまとめようかと思います。


さて、いつの時代でも人気な Topic がパフォーマンス改善・ボトルネック解消ではないでしょうか。

しかし、なまじ異常系の Topic だけに複雑であり、誤解や神話が多いのも事実ではないでしょうか。


まず大前提として、以下を押さえる必要があります。




1. パフォーマンスは最遅コンポーネントのパフォーマンスに従属する。

現在のシステムは、様々なコンポーネントや要素が複雑に絡み合っています。

仮にコンポーネントが以下の 3 つがあったとします。

A : 毎分 10 要求分の処理を行える

B : 毎分 8 要求分の処理を行える

C : 毎分 50 要求分の処理を行える

ここで、このシステムでは A ⇒ B ⇒ C の順に処理を行うとします。

そうすると、このシステム全体では毎分 8 要求しか処理できません。

B がボトルネックです。


さて、ここで B に投資して処理能力を 10 倍の毎分 80 要求の処理を行える状態にしたとします。

(ディスク IO のコンポーネントであれば、RAID 1+0 を導入する、など)

そうするとシステム全体のパフォーマンスはどうなるでしょうか。


毎分 10 要求しか処理できません。

1.25 倍にしかなりません。


システムが遅いからといってそのボトルネックを解消しても、隠れボトルネックが存在する場合、それが顕在化するため、解決にはなりません。

このため、ともすると効果を見誤ることになります。

ですので、常に測定とボトルネックの判別が非常に重要になります。


ちなみにボトルネックの解決は Try & Error と経験と勘、という話も聞きますが、ある意味正しく、その一方上記の意味で不適切だと考えています。

症状から原因が特定できるケースなどは、経験と勘が有効ですし、Try するのが最速の解決方法です。

一方で未知の障害に関しては、そのようなやり方では運任せとなり、泥沼になりかねません。

自身の経験と、直面している問題、求められる作業水準に応じて手法を取捨選択するというのが正しいと考えています。




2.現象と原因が直結するとは限らない。

これは、例えば以下のようなケースです。

ディスクの IO が非常に多く、そのため処理が遅いサーバがあるとします。


しかし、実はプログラムの質が低いためにメモリを大量に消費し、メモリ不足のために仮想メモリを大量に使用し、仮想メモリのためにディスク IO が非常に多くなっているかもしれません。

この場合は、根本解決はプログラムの改修ですが、メモリやディスク負荷からハードウェアの性能不足や、SQL Server の性能不足と判断してしまうこともありえます。


原因から現象が発生し、その現象が原因となってさらに別の現象を発生させることがあるため、原因らしき事象があった場合に、それが真の原因かどうかを検討する必要があります。




3.費用対効果を考える。

これも、上記の例の場合を考えてみます。


当然根本的な解決はプログラムの改修ですが、開発会社との取引が現在無いか改修のコストが非常にかかってしまう場合、プログラムの改修が難しい場合は、実は無理してプログラムの改修を行うより、より高性能なサーバーにリプレースするほうが安く問題を解決できる場合が多々あります。


研究ではなく業務で行っている技術者にとっては、根本解決ではなく回避策(ワークアラウンド)で対処というのも現実解としてありえます。

これを常に念頭において、根本解決が困難な場合には逃げ道を考えることも、意外と大事だったりします・・・。




このあたりを考えつつ、追加投資無しで行える調査手法やパフォーマンス改善について、次回以降言及・検討していきたいと思います。

接続プロトコル (TCP/IP)

こんにちは、nagino です。


SQL Server では接続プロトコルとして以下の 4 つがサポートされています。


-1. 共有メモリ(Shared Memory)

-2. 名前付きパイプ(Named Pipe)

-3. TCP/IP

-4. VIA


このうち、1 はローカル接続専用、4 は特殊なハードウェアが必要なため、通常は 2 と 3 が使用されます。

パフォーマンスや名前解決の問題から、通常はローカル接続では 2、リモート接続では 3 を使用します。


実際に使用しているプロトコルは、sys.dm_exec_connections で確認できます。

例えば以下のクエリで詳細を把握できます。


SELECT
net_transport,
*
FROM sys.dm_exec_connections


さて、2 は TCP ポート 445 で構成されるので良いのですが、3 についてはポートの構成を様々な形で行うことができます。


無名インスタンス(既定のインスタンス)の場合はポート番号は固定となり、IANA に登録されている TCP 1433 で待ち受けしますので、サーバ側もクライアント側も特に接続に支障はありません。

しかし名前付きインスタンスの場合は、デフォルトでポート番号が可変(動的)となります。


もちろん固定にし、FireWall やクライアント側で明示的に指定するのも可能ですが、動的な割り当てとすることもできます。

その場合は SQL Server Browser サービスを使用するのが一般的です。

これは UDP 1434 で待ち受けするサービスで、ローカルで起動している SQL Server のインスタンス名とポート番号を管理しています。

クライアントは UDP 1434 に接続し、接続文字列にあるインスタンス名に対応する SQL Server のポート番号を取得し、その後入手したポート番号で SQL Server に接続します。

このため、ポート番号が可変でも問題なく接続できるようになります。

ただし、この場合は FireWall の構成を工夫する必要があります。(ポート番号での指定ではなく、実行ファイルでの指定など)


野良エンジニアの足跡-SQL Server : TCP/IPの構成パターン


DataGrid ヘッダ行で改行

こんにちは、nagino です。


WPF の DataGrid ですが、横幅を節約したいためにヘッダ行で改行したいときの改行方法です。

野良エンジニアの足跡-DataGrid ヘッダ行で改行


<my:DataGrid ...>
<my:DataGrid.Columns>
...
<my:DataGridTextColumn Header="1行のヘッダ" Binding="{Binding BindingSomething}" />
...
<my:DataGridTextColumn Binding="{Binding BindingSomething}">
<my:DataGridTextColumn.Header>
<TextBlock>1行目<LineBreak />2行目</TextBlock>
</my:DataGridTextColumn.Header>
</my:DataGridTextColumn>
...
<my:DataGridTemplateColumn>
<my:DataGridTemplateColumn.Header>
<TextBlock>テンプレートでも1行目<LineBreak />2行目</TextBlock>
</my:DataGridTemplateColumn.Header>

</my:DataGridTemplateColumn>
...
</my:DataGrid.Columns>
</my:DataGrid>


太字のところがポイントで、Header 属性をタグで指定して、中身に改行を受け付けるコントロールを入れてしまうということです。

列のタイプは DataGridTextColumn でも DataGridTemplateColumn でもその他でも、不問です。

ここでは TextBlock と LineBreak を組み合わせて使っていますが、Wrap(自動改行) するものを使えば列幅に応じて自動的に、といった応用もできるかと思います。(未確認ですが)

Microsoft MVP(Data & Storage - SQL) 認定

こんにちは、nagino です。

普段は技術ネタ限定ですが、珍しく自身の記事です。


それで、この度 2009 年 4 月より Microsoft MVP(Data & Storage - SQL) に認定されました。

1 年間 MS MVP とのことで、より一層研鑽に励まないといけません。


MS MVP は自薦と、過去 1 年間のコミュニティ活動の実績に関して日本・米国 Microsoft 社の審査が必要です。

ただし、技術的に優れているかどうかではなく、継続的にコミュニティに貢献しているかどうかがポイントになるようでして、このように私程度の技術レベルでも認定されます。 ←ここ重要 :-)


認定されると Visual Studio Team Suit + MSDN Premium Subscription 1 年間の権利ですとか、色々と特典があります。

これのおかげで、継続的にコミュニティ活動をする際の必要経費がかなり軽減できます。


もしご興味がある方は以下から自薦登録できますので、挑戦されてみてはいかがでしょうか。

http://www.microsoft.com/japan/communities/mvp/selfregistration.mspx

自薦は年 4 回、3 ヶ月ごとに募集されます。

今は 7 月認定者対象として 4/19 まで募集しています。