SR の対応事項
お客さんからのアーキテクチャ相談で迷ったので、中の人に聞いてみた。
結果、SR はアーキテクチャの相談とかは承っていないみたい。
SR の対応範囲をあたくしがよく分かっていなかった。反省。
アーキテクチャ相談などはプレミアサポート内のプロアクティブメニュー（有償）で可能。
MS のエンジニアとディスカッションしたり、MS のエンジニアにてレビューをするという支援自体はしてもらえる。
※スコープ・工数によるけど。
以下、質問と回答。
回答対象ではないのに丁寧に回答してもらったので、ほぼ原文ママ。
お客さんの情報があったからだいぶ端折ってるけど、構成図とか作って説明してた。
＜質問内容＞
お客様より、Azure Data Lake Gen2 にデータを溜めて、そのデータを API 経由で取得したいという相談がありました。
お客様的には、BI 側で全データを持っているため、DWH は持ちたくないようです。
上記の条件において、Azure Data Lake Gen2 の利用方法として正しいアーキテクチャとなりますでしょうか。
また、上記の条件において、懸念点等はありますでしょうか。
＜回答＞
大変恐れ入りますが、弊社サポート部門ではシステムのアーキテクチャ案についての妥当性については、個別の SR より回答させていただくことは出来かねます。
具体的にどの部分の確認がしたい、また、こういったことをやってみたがエラーが出て実現したいことができないなど、トラブルシューティングをメインにご支援させていただいております。
そのため、本ケースに関しましても、現時点で頂いている情報について、ドキュメントベースでの一般的な回答となること、ご了承いただけると幸いです。
まず、ADLS Gen2 はディレクトリ管理系のオペレーションのパフォーマンスが Blob ストレージに比べて優れています。
そのため、ファイルシステムのように扱うようなユースケースの場合（時系列データを格納する場合など）や、フォルダーレベルでアクセス権限を付与したい場合などは、ADLS Gen2 が選択肢となります。
【参考：Azure Data Lake Storage Gen2 の使用に関するベスト プラクティス】
Data Lake Storage Gen2 に特化したパフォーマンスに関する公開ドキュメントは御座いませんが、Premium SKU の Data Lake Storage Gen2 については、Premium SKU ブロック Blob と同様に、最適化されたソリッドステートドライブ（SSD）に格納されるため、
同等のパフォーマンスメリットを享受することが可能です。
以下のドキュメントに Premium SKU のパフォーマンスの記載が御座いますので、ご確認いただけると幸いです。
API 実行頻度によるシステムへの影響については、実際のリクエスト量やどのような操作をするかに依存する部分のため、下記の内容をご確認いただいた上で、お客様にて検証いただければと存じます。
【参考：Premium ブロック BLOB ストレージ アカウント】
トランザクション料金についてですが、以下のドキュメントの「操作とデータ転送」の項目に、操作ごとのコストについての記載がございます。
そのため、まずはどの操作をどの程度利用するかなどの具体的なユースケースを立てていただいた上で、ご検討いただくのが良いかと存じます。
【参考：Azure Blob Storage の価格】
最後に、アーキテクチャーセンターというドキュメントがございますので、Azure 上でのアーキテクチャー選定をする際のご参考にしていただければと存じます。
【参考：Azure アーキテクチャを参照する】
うーん、結局どうなんだろう？ やったことないから、想定がつかないわ。
アーキテクチャセンターにも、そんなん無かったし。あたくしだって最初にそこ見たわ。
もちろん API コールの頻度にもよるけど、イメージ的には「API で共有フォルダをつつきに行く」って感じで、ADLS Gen2 のパフォーマンス出ない気がするんよね。。。
あと、ADLS Gen2 のランニングコストかかりそう。
データ読み出しにも金かかるしねぇ～。
Ura チョコスチームケーキ
グランスタに用事があった際に、いつも何か送ってくれる妹と自分自身へのお土産を買ってきた。
（あたくしは 4 個入り、妹に送ったのは 8 個入り）
チョコ好きな我々姉妹にとって、まぁハズレではないだろうと。
「チョコスチームケーキ」という名前だけど、ケーキ感は無くて、どっちかっていうと生チョコかなー。
そんなに甘ったるくなく、チョコに全ステ振りしてる感じ。もったりしてる。特に冷やしたら。
冷やして食べた方が生チョコ感が増すかな。常温で食べると食感的にふわっと感があるよ。
気を付けてほしいのが、チョコスチームケーキの個包装の下に食べるための楊枝（プラスチック製・切ったりできるやつ）がついていること。
あたくしも妹もゴリラやから、手づかみであむって食ってから気づいたんよね。。。
あたくしはマイドリンク「午後の紅茶 おいしい無糖」をお供にいただきました！
セルフホステッド統合ランタイム（IR）の設置場所について
コレ、前から気になってたこと。
案件でちょっと迷ったので、中の人に聞いてみた。
結局、セルフホステッド IR を立てるのは、オンプレでも Azure でも、どっちでもいいみたい。Azure 側にある必要性は無さそう。
どちらに立てるかは、お客さんのオンプレ環境のネットワーク要件・構成に依存する模様。
ベストプラクティスから外れても、デメリットがあるわけではないみたい。
以下、質問と回答。
＜質問内容＞
セルフホステッド IR を Azure 上の VM に設置する場合と、オンプレミス環境に設置する場合のどちらが適していますでしょうか。
セルフホステッド IR はオンプレミス側のデータを吸い上げる役割だと認識していますので、オンプレミス環境側に立てるもどだと思っていました。
（Docs のに描かれている絵も、セルフホステッド IR はオンプレミス環境側に描かれていることが多いように思います。）
しかし、セルフホステッド IR の ベストプラクティス では、Azure 側に立てることも推奨されていました。
個人的には、セキュリティの観点から、極力 Azure 側に VM を立てたくないと思っています。
ベストプラクティスから外れると、何かデメリットがあるのでしょうか。セキュリティベースラインみたく、順守しないといけないのでしょうか。
＜回答＞
お客様のデータストアを含めたネットワーク構成にも依存し、ケースバイケースとなる。
ただし、リソースの競合を防ぐ目的で、セルフホステッド IR をデータを保持するオンプレの環境にインストールしないことを推奨している。
～セルフホステッド IR の使用に関する注意点～
- セルフホステッド IR は、データソースと同じコンピューター上に存在する必要は無い。
- しかし、セルフホステッド IR をデータソースの近くに配置することにより、セルフホステッド IR からデータソースへの接続時間が短縮される。
- セルフホステッド IR は、オンプレミスデータソースをホストするコンピューターとは異なるコンピューターにインストールすることを推奨する。
- セルフホステッド IR とデータソースが別のコンピューター上にある場合、セルフホステッド IR ではリソースのデータソースとの競合は発生しない。
- その他の注意事項は セルフホステッド IR の使用に関する注意点 を参照のこと。
うーむ、明確な答えではないなー。
フル PaaS で作りたいのに、IaaS が立っちゃうのが嫌なんよね。要件定義、設計ともに分量が増えてめんどくさいから。
主にセキュリティ系の運用部分が増えるからやりたくないんよなー。
「誰が VM のお守りをしますか？」「Windows Update のタイミングはいつにしますか？」「マルウェア対策はどうしますか？」「セルフホステッド IR のアップデートはどうしますか？」とかとか、聞くことが増えるんよね。。。
AutoResolveIntegrationRuntime の利用用途について
AutoResolveIntegrationRuntime と Azure IR の使い分けが今ひとつ理解できなかったので、中の人に聞いてみた。
AutoResolveIntegrationRuntime ＝ "地域" の変更できない Azure IR のことだった。
この子（AutoResolveIntegrationRuntime）はちょっと特殊な Azure IR だったんやね。
AutoResolveIntegrationRuntime は以下の点がメリットみたい。
- IR の使い回しが可能。
- 常にシンクに近いリージョンを検知（”自動解決”）する。（シンクに近いリージョンの IR を使うことで通信速度が上がる）
以下、質問と回答。
＜質問内容＞
以下 URL より、AutoResolveIntegrationRuntime は Azure IR と同義と認識しておりますが、認識は正しいでしょうか。
【既定の Azure IR】
AutoResolveIntegrationRuntime を明示的に使う場合として、以下 URL に記載のあるようにプロキシ構成の一環としてステージング環境に置く以外にありますでしょうか。
【Azure Blob Storage のリンクされたサービスをステージング用に準備する】
例えば、コピーアクティビティを使ってオンプレミス環境にある SQL Server から SQL Database にデータをコピーする場合、以下の設定でも良い気がするのですが、認証情報はどのように引き継がれるのでしょうか。
ソース側（SQL Server） ：セルフホステッド統合ランタイム
シンク側（SQL Database）：AutoResolveIntegrationRuntime
＜回答＞
「AutoResolveIntegrationRuntime は Azure IR と同義」という認識通り。
AutoResolveIntegrationRuntime は Data Factory をデプロイした時点でデフォルトで作成される Azure IR のこと。
自動解決の仕組みとしては、「Azure IR の場所」 を参照のこと。
※文中にある「規定の設定である自動解決の Azure IR」は、AutoResolveIntegrationRuntime のことを指している。
Azure IR の場所
新規に作成する Azure IR においても、リージョンを ”自動解決” で設定することができるが、AutoResolveIntegrationRuntime においてはリージョンの変更ができない点が異なる。
「1.」で回答した通り、AutoResolveIntegrationRuntime はリージョンが ”自動解決” の Azure IR である。
シンクに近いリージョンの IR を使うことで処理能力が上がるため、”自動解決” でシンクのリージョンを検知することはメリットがある。
一方で AutoResolveIntegrationRuntime は設定の変更ができないため、以下の場合は Azure IR を新規作成して利用する必要がある。
・データコンプライアンスの要件が厳しく、データが地理的な特定の場所を離れないようにする必要がある場合。
・リンクサービスの種類において、IR のリージョンを明示的に指定する必要がある場合。
（例：Office 365 コネクターの場合、IR のリージョンは Office 365 のテナントの場所と同じである必要がある）
・データフローのコンピューティングを変更し、データフローのパフォーマンスを上げたい場合。
コピーアクティビティにおいて、セルフホステッド IR と Azure IR が同時に使われることは無い。
該当のシナリオの場合、コピーアクティビティではセルフホステッド IR が適用される。
詳細については、「使用する IR の判別」 を参照のこと。
コピーアクティビティ
Azure IR を立てて、シンクに近いリージョンの IR を明示的に指定する方法の方が、リージョンを検知しない分処理は早くなるんじゃない？と思ったんだけど、それでももちろん問題無いとのこと。
（「仰る通り、リージョンを検知しない分の処理は早くなると思います。」との回答）
特定の条件が無かったら、基本 AutoResolveIntegrationRuntime を使っておけば良さそうやね。
【その8】詳細設計書論争
今から 4 年以上前に MBO に書いてしまった、新人ちゃん向けのメルマガが出てきた。
これで終わり！どんだけ新人ちゃんにインプットできたのかは分からんけど。
実は、メルマガとして記載していたのは前段部分のみで、後はパワポの資料に書いてたんよね。
さすがにパワポは引っこ抜けないから、ブログには全部平文で書いてるけど。
詳細設計書を作るかどうかについては、正直、いろんな会社のいろんなエンジニアに聞いてみたい。
このメルマガを書いた当初は詳細設計書必要派だったんだけど、今は迷ってる。
メリット / デメリットはもちろんあるけど、今の開発環境、開発スタイル等々によっても変わると思うの。
ノーコード / ローコードだとパラメーターシート（パラシ）が詳細設計書に相当すると思うし、
そもそも詳細設計書という概念が無いのかもしれない。
- 詳細設計書を作成するのかしないのか、
- 作成するとしたら、どんなものを作っているのか、
- 作成しないとしたら、品質担保はどのように顧客に説明しているのか、
- 普段、詳細設計書を作成しないけど、顧客の成果物に入っていた場合はどうするのか（少なくとも公共系は未だに求められているのは確認できてる）、
・・・
どれが良い / 悪いをジャッジしたいんじゃなく、純粋な興味から聞いてみたいものだわ。
※以下、当時の文章。
皆さんは詳細設計書って見たことありますか？
私はこの会社（※当時所属してた会社）に入って、2 プロジェクトしか見たことがありません。
基本設計書にがっつり記載しているから詳細設計書は不要、とか、工数に無いから、とか、そもそも詳細設計書を作る文化が無いから、とか・・・。
そういう声を聞いたりもします。
しかし、もし詳細設計書を書かなかった場合、どうやって単体テストを行うのでしょうか。
ウチの会社（※当時所属してた会社）は、ウォーターフォール開発モデルを標準としています。
上記に倣うと、詳細設計書の内容が単体テストの項目になるため、詳細設計書が無いと単体テストができないことになってしまいます。
今回は、詳細設計書を書くとしたら、何が・どんなことが必要となるか？を記載しました。
詳細設計とは
1）実装の前段階
実装の前段階で行われる場合は、内部設計や機能設計などで定義されたシステムの構造や仕様などをプログラム単位に分割し、各プログラムの動作を定義していく工程を意味することが多い。（≒プログラム設計）
2）プログラム設計の前段階
プログラム設計の前段階で行われる場合は、基本設計や概要設計で定められた機能や操作・表示方法などに基づいて、システムとしてそれをどう実現するかを具体的に定めていく。（≒内部設計）
→ ここでは、2）の意味とします。（ウチの会社ではプログラム設計書は記載しないため）
ウチの会社での詳細設計書
この会社で「詳細設計書」と呼ばれるドキュメントはほとんど見たことがありません。
この会社で詳細設計書を作成したのは、X 億以上の公共案件ぐらいでした。
（前職では必ず記載していたので、入社直後はカルチャーショックを受けました・・・）
＜詳細設計書が無い理由（たぶん）＞ ※私見です！
- そもそも作成する文化が無かった。
- 納品物に無いから作成しなかった。（業種、業界によって異なる部分があるため）
- 超大型案件以外は作成しない方針である。（工数の関係）
→ じゃあ、詳細設計書は作成しなくていい？
詳細設計書が無い場合
詳細設計書が無い場合、開発時には何とかなるかもしれませんが、保守開発時に新規メンバーが参画した場合、以下のことで困ることが多いです。（経験談）
- アプリケーション
- 基本設計書と実際のコードをひもづけるものが無いため、基本設計書を実装したコードファイルがどこにあるのか分からない。（物理名が分からない）
- 共通処理を使っている部分が見えにくい。何が共通処理となっているのか、どこで使われているのかは、ソースを Grep しないと分からない。
- ミドル・インフラ
- IIS の設定等、設定値の根拠が分からない。
- どこからどこにリダイレクト、リバースプロキシを行っているのかが分からない。
詳細設計書に欲しいもの
上記の内容を基に、詳細設計書に欲しい内容を以下に一例としてまとめました。
＜詳細設計書に記載してほしい内容＞
| 記載してほしい内容 | 概要 |
|---|---|
| ファイルの物理名と絶対パス | 基本設計書の内容がソース上のどこにあるかを記載します。 ひもづきを表す一覧を作成する方法もあります。 |
| 共通処理仕様 | 他の設計書同様、インプットとアウトプット、処理フローを記載した設計書を作成します。 |
| パラメーターシート（アプリ用） | インフラのパラメーターシートとは別に、アプリ側で設定した内容を記載します。 |
| リダイレクト・リバプロ仕様 | リダイレクト・リバプロ元、リダイレクト・リバプロ先を一覧にまとめます。 （他案件でも作成しています。基本設計書に持ってきているかも？） |
＜補足＞
※以下、私見です！！
上記の内容が全て基本設計書に含まれている、かつ、基本設計書の処理フローが詳細であれば、詳細設計書は不要な場合があるかもしれません。
今回で最後となります。
これで設計に強いエンジニアになれる・・・はず！
最後までお読みいただき、ありがとうございました。
香炉庵 東京鈴もなか
グランスタに用事があった際に、いつも何か送ってくれる妹と自分自身へのお土産を買ってきた。
この最中だけは自分だけのために買ったもの。
【香炉庵オンラインショップ】 東京鈴もなか(4袋入);横浜元町香炉庵
（2 個入りを購入。1 個は速攻食った）
開けるとドラえもんの鈴みたいな形の最中が 2 つ。
あんこはこしあん。上品な甘さ。
真ん中におもちっぽいものが入ってるのが、個人的に高ポイント。
あんこあんこしすぎず、もちもちで美味しさ&食感が増す。
最中なんで、最中の皮が上顎に付くのはご愛嬌。そうなるの、あたくしだけ？
あんまり和菓子を好んでは食べないあたくしも、コレはとても美味しく頂けたなぁ。
コレはお茶やね～。緑茶。
家にあった綾鷹を温めて頂きました！
チョコ in かきたね キャラメル味
と一緒に、真ん中の妹が送ってくれた 1 品。
（ホントはもう一袋あったんだけど、速攻食べちゃったんよね）
このかきたねは、間違いなくおやつ。
サクサクのかきたね（ちょっとクッキー風？）中に、ホワイトチョコ（キャラメル風味）が入ってた。
キャラメル風味がとても良き。甘ったるく無く、食べやすい。
真ん中の妹はコレが好きって言ってたなー。
もちろん、甘いもの好きなあたくしも例外無く好き。
あたくしは白ワイン（辛口）のアテにしました。
辛いのと甘いののコラボは良きですな。
