-
Notifications
You must be signed in to change notification settings - Fork 0
MS_AzureInfraDevelopment
- クラウドの特性
- スクラップ＆ビルドが非常に容易かつ低コストでできる
- インフラ構築（基盤構築）を容易にスクリプト化することができる
- この特性を生かしたシステム構築を行うことが重要
インフラ構築に関して、まず最初に意識するべきポイントは以下の 4 つ
ウォータフォール型開発（V 字型モデル開発）が抱える根本的な問題：
『後工程を完全に見通せていない場合、必ず何らかの手戻りが発生する』
クラウドのメリットは、この『後工程の先取り』が容易に行えること
- 技術トレーニング
- Try & Error 型開発
- プロトタイピング
- スパイラル型アプローチ
- PoC（Proof of Concept）
- アジャイル開発
移行メモ（体裁）: 原典の「プロタイピング」は
「プロトタイピング」の誤りであるため修正した。
補足（この主張の核心）: 「後工程の先取り」という言い方が
本ページで最も重要な概念である。
従来と何が変わったのかを整理すると次のようになる。
オンプレミス クラウド 環境の入手 調達・設置に数週間〜数か月 数分 失敗のコスト 高い（買ってしまったものは戻せない） 低い（消せば課金も止まる） 検証の位置 設計を固めてから（後工程） 設計と並行して（先取り） 手戻り 致命的 織り込み済み つまり、ウォーターフォールが手戻りを恐れて
「机上で完璧に設計する」方向に進化したのは、
環境を作るのが高価だったからである。
その前提が崩れた以上、
「まず作って確かめる」方が安く速い、というのが本節の主張である。これは開発プロセスの流行の話ではなく、
調達コストという制約条件の変化に対する合理的な帰結として
理解するのが正しい。
| PoC 環境 | 開発環境 | 本番環境 | |
|---|---|---|---|
| 利用目的 | 基盤とアプリのプロトタイピングや技術検証作業 | アプリの開発とテスト | 本番システムを運用 |
| ネットワーク位置 | オンプレと接続しない | オンプレ（開発 LAN）からの延伸 | オンプレ（本番 LAN）等からの延伸 |
| ネットワーク閉域化 | しない | する | する |
| Microsoft Azure Active Directory | PoC 管理用 | 開発系 VDC 管理用 | 本番系 VDC 管理用 |
| 作業権限 | 開発チーム権限 | 開発チーム権限 | 運用チーム権限 |
| 環境管理者 | PoC 基盤担当 | PoC 基盤担当 | VDC 基盤担当 |
| 環境利用者 | インフラ・アプリ開発チーム | （大規模）アプリ開発チーム | エンド・ユーザー |
| 本番やテストのデータ | 持ち込み不可 | 利用可能 | 利用可能 |
| 監査対象 | NO | YES | YES |
移行メモ（表の変換）: 原典は PukiWiki のセル結合記法（
>）を
使用していたため、結合されていたセルは同じ値を展開して表現した
（GitHub の表記法にセル結合が無いため）。
結合されていたのは「ネットワーク閉域化」「作業権限」「環境管理者」
「本番やテストのデータ」「監査対象」の各行である。
補足（この表の要点は「PoC 環境だけが浮いている」こと）: 3 つ並べているが、
開発環境と本番環境は性質が近く、PoC 環境だけが異質である。
表を縦に読むとそれが分かる。
観点 PoC 環境 開発・本番環境 オンプレとの接続 しない する 閉域化 しない する 実データ 持ち込み不可 利用可能 監査 対象外 対象 つまり PoC 環境は、
「実データを持ち込まない代わりに、統制を緩めて速度を得る」
という設計になっている。
この交換条件が成立するのは実データが無いからであり、
ここで「ちょっとだけ本番データを持ち込む」と
前提が崩れて一気にリスクになる。「持ち込み不可」が単なる規則ではなく
PoC 環境の存在を支える前提条件である、という理解が重要である。なお、VDC（Virtual Data Center）は
オンプレミスのデータセンターに相当する構成をクラウド上に作る考え方で、
現在は Enterprise-Scale ランディング ゾーン
（Cloud Adoption Framework）として体系化されている。
OA 用と運用用のテナントを分離する。
補足: この方針の理由は
AzureのPoC環境を契約するに整理してある
（本番テナントで PoC をやると権限・ポリシー・監査が巻き添えになる）。
- PoC 環境の費用
EA 契約からサブスクリプションを払い出せば、より容易。- 負担
- 管理
- PoC 環境のセキュリティ
- 踏み台にされる恐れ
- Azure Security Centerなどで定期スキャン
- 定期的な削除＋IoC による再生成
- 利用者が悪事を働く恐れ
開発ベンダに対して貸し出す場合には心配がある。- 契約で縛るのが基本
- 真正性、責任追跡性、否認防止（.NET開発基盤部会 Wiki）を可能にしておく。
- 踏み台にされる恐れ
補足（「定期的な削除＋IaC による再生成」が最も効く）: 原典の「IoC」は
文脈から **IaC（Infrastructure as Code）**を指すものと読める
（直後の節が「IaC 技術のフル活用」であるため）。この一行は、PoC 環境のセキュリティ対策として
極めて効果的である。理由は次のとおり。
効果 内容 侵害の永続化を防ぐ 環境が定期的に消えるため、仕込まれたバックドアも消える 設定のドリフトを消す 検証で緩めた設定が残り続けない コストが下がる 使い終わった環境が残らない IaC が常に検証される 再生成が日常なので、テンプレートが腐らない セキュリティ対策としてスキャンや監視を積み増すより、
**「そもそも長生きさせない」**方が確実で安価である、という発想であり、
クラウドならではの考え方である
（Immutable Infrastructure の考え方に通じる）。
IaC技術のフル活用
- オペミス防止
- コスト削減
- 設計・実装の再利用
- 容易な繰り返し環境構築
- 未使用時のリソース解放
- 基盤構築の進め方
- ポータルサイトを使って手作業で構築する。
- 手順を精緻化しながら、IaC化する。
- 設計ドキュメントの作り方
膨大なパラメタ・シートを作成しない。- インフラ・アーキテクチャ概要図
- 実環境からエクスポートされた情報
補足（「膨大なパラメタ・シートを作成しない」が本節の白眉）: この一文は、
IaC がドキュメントのあり方を変える、という重要な指摘である。従来、インフラの設計書は
Excel のパラメタ・シートとして作られてきた。
しかしこれには構造的な問題がある。
問題 内容 二重管理 シートと実環境の両方を保守する必要がある 必ずズレる 実環境を変更してもシートは更新されない どちらが正か分からない 差異が出た時に判断できない IaC ではこれが解消される。
【従来】 パラメタ・シート（設計） ≠ 実環境（実装） … ズレる 【IaC】 テンプレート（設計＝実装） ＝ 実環境 … ズレようがないテンプレートそのものが設計書になるため、
人が読むために別途必要なのは
- 全体像を示す図（テンプレートからは読み取りにくい）、
- なぜそう設計したかの理由（コードに書けない）
の 2 つだけになる、というのが本文の主張である。
「実環境からエクスポートされた情報」は、
常に実物と一致するという点で、
手書きのシートより信頼できる。なお、進め方として
「まずポータルで手作業 → 精緻化しながら IaC 化」を推奨しているのも実践的である。
最初から IaC で書こうとすると、
何を書けばよいか分からず手が止まる。
ポータルで作った構成はテンプレートとしてエクスポートできるため、
それを出発点にするのが早い
（Azure上に素早く環境を構築する）。現在は ARM テンプレート（JSON）より Bicep が推奨されている
（クラウド・インフラ自動化）。
クラウドを安全に使いこなすためには、一定の基礎スキルが求められる。
- 課題：SI 子会社や大手 SIer のプロパーの PjM/SE は技術に触れる機会が少ない
- 解決：PM, SE もクラウドを触ってみる。Microsoft Learn で手触り感を探る。
- 課題：クラウドではアプリとインフラの垣根がますます低くなる。
- 解決：全体のグランドデザインはアプリ側で考えてしまった方が早い。
- 課題：『不適切な実装』『セキュリティ的に危険な実装』が発生する。
- 解決：事前にクラウドの学習時間を取り、実際に触りながら学習する。
補足（3 つの「スキル不足」に共通する構造）: 一見バラバラだが、
いずれも**「役割分担の前提が変わった」**ことに起因している。【オンプレ】 アプリ担当 ─── 明確な境界 ─── インフラ担当 （設計書で受け渡し。境界が動かない） 【クラウド】 アプリ担当 ≒≒≒ 曖昧な境界 ≒≒≒ インフラ担当 （PaaS を選ぶかどうかで境界そのものが動く）例えば「Web アプリをどこで動かすか」は、
- VM（インフラ担当の領域が大きい）
- App Service（境界が上に移動）
- Functions（境界がさらに上に移動）
のどれを選ぶかで責任分界点そのものが変わる
（Azureの高可用性設計の責任分界の表を参照）。そして、この選択はアプリの要件によって決まる。
だから本文は「グランドデザインはアプリ側で考えた方が早い」と
結論しているのであり、これは組織論ではなく
技術的な必然である。「セキュリティ的に危険な実装」が発生しやすいのも同じ理由で、
従来インフラ側が担保していたこと
（ネットワーク境界、認証、鍵管理）が、
アプリのコードや構成に移ってきているためである
（接続文字列の埋め込み、パブリック アクセスの開放など）。
Azure Key Vaultやマネージド ID の
知識がアプリ開発者にも要る、という話になる。
※ Azure 仮想ネットワーク基礎（Azureの仮想ネットワーク）中の
「クラウドの特性をフル活用した基盤開発方法」にも同様のトピックが含まれる。
Tags: 移行, インフラストラクチャ, クラウド, Azure
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。