##背景
後の事を考えず、AWS上に複数のシステムを継ぎ足し継ぎ足しでガシガシ開発していくと、ごちゃごちゃになって、どうにもならん。って事ないですか？そうならないためにも、後に複数システムが稼働する環境（つまり標準化環境）を開発する際に考えた事をつらつら書いていこうと思います。
##標準化の目的を考える
前提として何を目的として標準化するのか？標準化に向けた検討の拠り所となる道しるべを定める必要があると考えます。つまり、標準化により誰にどのような効果やメリットを提供するのか明確にする必要あり、この目的の明確化が最重要と考えます。
- 標準化の目的（例）
- 個々のシステムの要求に応じ、迅速に環境を払いだし開発スピードの向上に寄与する
- 統一されたセキュリティ基準に沿ったシステムの展開によるセキュリティ事故の未然防止
- 最低限のセキュリティ基準は満たしながら、クラウドの特性を十分に活用すべく、アプリケーション開発に有効となるPaaS機能の開放（個別システムにクラウドサービス利用の自由度を与える）
- 個々のシステム個別で考えてきた、同種の機能を共通機能として実装し、個別システム開発の負荷を軽減する
- 個々のシステムで共通項となる運用を一元的に管理し、運用効率化を実現すると共に運用品質を向上させる
- 既存システムからの確実で迅速な移行
##標準化の対象箇所を考える
標準化対象の範囲を定義し、個々のシステムで開発する範囲、標準化基盤で提供する範囲を明確にする必要があります。例えば、システムの例として赤背景の箇所を標準化対象とする場合のシステム構成概要は概ね下図のようになると思われます。
##標準化検討の観点
- インフラ基盤
原則、複数企業が同一環境を共同利用するマルチテナント環境と認識し、クラウドサービスが提供する環境分離機能やデータ分離、認可機能等の活用を検討し、資産の混在を防止する
| 検討項目 | 検討内容 |
|---|---|
| アカウント管理 | 契約単位となるアカウントの適用範囲や方法。また、アカウント間の連携を意識したアカウント構成方法 |
| 認証、認可 | クラウドサービス管理コンソールへ接続する際の認証、認可の方法。運用チーム体制（どのチームが何の運用をするのか）と、認可は密に連携するため、詳細に検討する必要あり。また、外部委託先の開発ベンダーに対する認証、認可の方法も必要。利用者が既存で利用しているIDを利用し認証したい場合など、個別ケースも要検討。 |
| シークレットキー管理 | クラウドから提供するシークレットキー（クラウドサービスをAPIで操作）の管理方法 |
| システムランク定義 | 個別システムのシステム重要度に応じた可用性、拡張性定義や構成パターン。また、個別システムにおける、本番、検証、開発環境の構成も意識する |
| 提供サービス | クラウドが提供しているサービスを何処までユーザに標準化し開放するのか。ユーザに開放するサービスについてサービス利用時に情報漏洩の可能性等、サービス仕様を確認、検証したうえで提供が必要 |
| 開発ガイドライン | 利用者（個別システム開発者）に提供する開発ガイドラインの作成。クラウドサービスの特徴、システム開発の流れ、設計・開発・運用のポイント、責任範囲等を解説する為の資料 |
- ネットワーク
インターネットとIN/OUTになる接続口を標準化基盤として提供するのか、各システムに委ねるのかを検討し、前者であれば、セキュリティ機能の適用を検討
| 検討項目 | 検討内容 |
|---|---|
| 個別システム内のサブネットの分割 | 個々のシステム内のネットワークセグメントの構成方法やセグメント間の通信制御方法 |
| 個別システム間のネットワークアクセス経路 | 個々のシステムどうしを接続するネットワークアクセス経路や通信制御方法 |
| 各社からのネットワークアクセス経路 | 利用者の各社から共通基盤にアクセスする際の接続パターンやネットワークアクセス経路 |
| 開発ベンダーのネットワークアクセス経路 | 利用者が個別システムの開発を外部開発ベンダーに委託した際の、開発ベンダーから共通基盤へのアクセス経路や通信制御方法 |
| インターネットから外部公開環境へのクセス経路 | インターネットから個別システムにアクセスする際のネットワークアクセス経路や通信制御方法 |
| インターネットへのアクセス経路 | 個別システムがインターネットにアクセスする際のネットワークアクセス経路や通信制御方法 |
| ドメイン管理 | ドメインゾーンの管理方法や、インターネットからのシステムの名前解決、また外部ネットワークからの当システムの名前解決の方法 |
-
セキュリティ
インプットとなるセキュリティポリシーに従い、標準化基盤では最低限のセキュリティ基準を満たし、利用者にセキュリティ対策を要求する箇所を明確にする -
非機能
受入想定の個別システムが個々に実装している非機能を整理し、標準化基盤として標準的に提供する非機能の見極め -
運用
運用項目を整理し、個別システムと標準化基盤の運用範囲の明確な定義 -
移行
既存システムからの移行パターンを整理、検証し、標準化基盤構成にマッチした移行方式の提供
##まとめ
複数システムが稼働する共通化基盤であるが故に考えないといけない事は多々あります。また標準化された基盤は末永く利用される環境であるため、後々の構成変更は容易ではなく、慎重に検討したいものです。
南野様も「3年間のプロジェクト中、ほぼ1年3ヶ月をこの標準化に費やした」と言われていますね。