セルフホステッド統合ランタイム（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 品。
（ホントはもう一袋あったんだけど、速攻食べちゃったんよね）
このかきたねは、間違いなくおやつ。
サクサクのかきたね（ちょっとクッキー風？）中に、ホワイトチョコ（キャラメル風味）が入ってた。
キャラメル風味がとても良き。甘ったるく無く、食べやすい。
真ん中の妹はコレが好きって言ってたなー。
もちろん、甘いもの好きなあたくしも例外無く好き。
あたくしは白ワイン（辛口）のアテにしました。
辛いのと甘いののコラボは良きですな。
【その7】基本設計書 ④API
今から 4 年以上前に MBO に書いてしまった、新人ちゃん向けのメルマガが出てきた。
そろそろ終わりが見えてきた。
たぶん疲れてたんだろう、前段が短い。内容も若干薄めやし。
API は・・・あんまやりたくなかったなー。
連携元、連携先システムを同時に自社で作るんならまだしも、大抵が現行システムや他ベンダーが作る別システムやもんなー。
とにかく調整が面倒！後手に回ったら開発が大変になることが多かった。
なので、先手先手で「ウチはこうします！お客様とも了承をうけています！」ぐらいで持っていかないと、こっちの思うようにならんからね。
ウチの利益が最優先。他ベンダー？(´・ω・`)知らんがな。やるかやられるかじゃ！
※以下、当時の文章。
基本設計書シリーズの最後を飾るのが API です。
基本的な進め方はバッチと少し似ていますが、連携相手が他システム（別ベンダー）となると、コミュニケーション能力がカギとなってきます。
特に現行システムだとなかなか調整が難しいところがあるので、「何をどうしてほしいのか」をできるだけ明確にする必要があります。
API 設計とは
1）ソフトウェアインターフェース
ソフトウェアインターフェースは、プログラム間でデータや指示をやり取りする手順や形式を定めたもの。代表的なものとして、OSやミドルウェア、ライブラリなどの機能を外部から呼び出して利用するため規約であるAPI（Application Programming Interface）がある。
→ ここでは、ざっくりですが「API 設計＝インターフェース設計」とします。
API 設計で決めること
大きく分けて、以下の 2 つです。
- 基本情報（API 仕様）
- 処理の流れ
※以下、私見です！
大まかな流れはバッチ設計と似ている気がします。
API 設計の方が相手（他システム）を意識する点、通信速度を気にすることが多い点で、設計の方法が異なりますが・・・。
１. 基本情報（API 仕様）
API の基本的な仕様を決めます。
主に、API の連携方法や入出力を決めます。
＜決める必要のある内容＞
| 内容 | 概要 |
|---|---|
| 処理区分 | API がどういう処理を行うのかを記載します。 データの取得（参照）か、データの更新かを明確にします。 |
| 配置場所 | API がどこに配置されるのかを記載します。 複数システムがある場合、サーバーによって API の配置先が異なる場合、特に必要です。 |
| 要求（連携元、連携方法） | 該当する API の呼び出し元のシステム（連携元）とインプット（連携方法）を記載します。 連携方法には JSON やファイル形式（CSV、TSV 等）を記載します。 |
| 応答（連携先、連携方法） | 該当する API の呼び出し先のシステム（連携先）とアウトプット（連携方法）を記載します。 連携方法には JSON やファイル形式（CSV、TSV 等）を記載します。 |
| 連携タイミング | API が呼び出されるタイミングを記載します。 |
| 説明 | API についての説明を記載します。 |
２. 処理の流れ
API 仕様で決めたインプットとアウトプットを具体化し、処理フローを記載します。
（何をもらって、何を返せばいいのかの明確化）
＜決める必要のある内容＞
| 内容 | 概要 |
|---|---|
| 処理フロー | API の起動タイミング～処理終了までを図式化します。 |
| 処理概要 | 処理フローにある項目ごとに、処理の概要を記載します。 |
＜補足＞
処理概要をどこまで書くか？という問題がよく出てきます。
※以下、私見です！！
個人的には「詳細設計書があるなら概要のみ、詳細設計書が無いなら処理概要に詳細を書く」方が良いと思います。
API 設計のコツ
- インプット、アウトプットをしっかり固めること
API を使用する際、必ず通信相手となる別システムがあります。
通信相手が既存サービスの場合（例：Yahoo API、等）、インプット、アウトプットは明確で不可変なので、そのルールの中で設計する必要があります。
通信相手となるシステムも構築中であれば、よく認識を合わせて仕様を決める必要があります。
※できるだけこちらから仕様を提示するのがお勧めです。相手に合わせてもらう方が設計・実装ともにラクになります。
- 処理速度に留意すること
オンバッチと同じく、API も画面側から呼ばれることが多いため、処理速度には留意してください。
API は別システムとの連携になるため、相手側システムｂに負荷がかからないように設計してください。
※その逆（API が呼ばれた際に、自システムに負荷がかからないようにする）も同様です。API を呼び出す頻度にも注意してください。
MEIDI-YA おいしいローストポーク
年末年始の楽しい酒ライフのため、Amazon でまとめてつまみを買った中の 1 つ。
【明治屋】スーパーマーケット｜商品情報｜商品情報一覧｜瓶・缶詰 ほか｜おいしいおつまみパウチシリーズ｜おいしいローストポーク
（「ローストビーフ」ってのもあったんだけど、それはお世話になってるおじさんにあげちゃった）
袋を開けるとツナっぽい香り。なんか美味しそうなにほひ。
食感も肉っていうよりかはツナっぽい。厚みがある＆食べ応えのあるツナみたいな。
スパイスが効いてて、お酒に合うね。
一瞬『犬のエサ？』と思ったあたくしを許しておくれ。
いつものハイボールとともにいただきました！
炭酸系のお酒が好きな人は好きな味かも。
