【aws】アーキテクト①接続方式

今回からは、AWSのアーキテクトについて学習していこうと思います。ただし、WEBサーバーやAPサーバーといった"機能的な"話については、作成しようとする業務に合わせて調べればいいと思っていて、取り扱っていくのは"非機能要件"が中心となると思います。

非機能要件の重要性

非機能要件はあまり聞きなじみがない方もいらっしゃると思いますが、商用利用の際にはこの"非機能要件"をクリアできて初めて、業務要件の話に入れる最初の関門となります。例えば、非機能の代表格であるセキュリティであれば、セキュリティの対応が弱いシステムは会社で利用しようとは思わない、のような話です。

参考とする資料

こういう学習をするときには、政府系の入札用の情報公開資料があてにできます。ちょうどデジタル庁から自治体向けに提供している"ガバメントクラウド"という閉域クラウドサービスの利用案内のサイトに、詳しい推奨構成が公開されていたので、こちらを参考にしながら、昨今のクラウドでの非機能アーキテクトを確認していきたいと思います。

• 地方公共団体の基幹業務システムの統一・標準化　(デジタル庁)
  • ガバメントクラウド利用における推奨構成（ZIP／13,655KB）
  • ガバメントクラウド利用における推奨構成（AWS編）.pdf(令和4年12月 加筆修正：令和8年3月)

指標/KPI

まず最初は、この推奨構成で観測できる指標/KPIを確認したいと思います。
P.11あたりの記載がそれにあたると思います。IPAで公表されている非機能要求グレード(*1)の分類方法とは違うようです。

※　指標値例は「令和5年度 ガバメントクラウドの先⾏事業（基幹業務システム）における調査研究 ⽬標管理指標の検証 検証結果」（デジタル庁）に記載されているものを併記しています。各管理指標の定義も記載しているので、興味がある方はご参照ください。

No	管理指標	指標値例
1	Cost（コスト効率、最適化）	• 運⽤コスト • 仮想サーバー・ストレージ等の利⽤料 • クラウド利⽤料 • クラウド利⽤料の実績と予算の⽐較
2	Elasticity（弾力性）	• エラーレート • レスポンスタイム
3	Performance（パフォーマンス）	• レスポンスタイム
4	Agility（俊敏性）	• インフラリリース時の準備時間・掛かる時間 • インフラチューニング回数
5	Velocity（ベロシティ）	• エラーレート • インフラリリース時の準備時間・掛かる時間 • インフラチューニング回数
6	Security（セキュリティ）	• 予防的・発⾒的統制違反の件数 • インシデント発⽣数
7	Resiliency（レジリエンシー）	• RPO、RTO等
8	Observability（可観測性）	• 各指標値の⽬標達成割合
9	Transparency（透明性）	• クラウド利⽤料の実績と予算の⽐較 • 各指標値の⽬標達成割合
10	Improvability（改善性）	• インフラリリース時の準備時間・掛かる時間 • インフラチューニング回数 • 各指標値の⽬標達成割合
11	Automation（自動化）	• インフラリリース時の準備時間・掛かる時間 • インフラチューニング回数

自治体特有のシステム用語

資料を読むうえで自治体の専門用語は以下の通りです。
※ 正確な定義は、省庁などのサイトを参照してください

No.	用語	意味
1	標準準拠システム	地方公共団体の基幹業務システムの統一・標準化に適合したシステム
2	LGWAN	自治体間をつなぐL3の閉域網
3	LGCS	LGWANガバメントクラウド接続サービスの略。LGWANとガバメントクラウドを仲介するサービスを提供するISPのような組織及びサービス

接続方式

初回となる本記事では「システム構成」のページを見ていきます。内容を読んでいくと、サーバーへの接続方式の話を記載していることがわかります。

引用元：ガバメントクラウド利用における推奨構成（AWS編）.pdf（デジタル庁）P.14

アイコン	名称	アイコン	名称
	private-cloud-VPC		Direct-Connect
	PrivateLink		Elastic-Load-Balancing
	VPC_Customer-Gateway		VPC_VPN-Gateway
	Direct-Connect_Gateway		VPC_Endpoints

アーキテクチャ概要

ここでは、主にAWS上のサーバーへのアクセス経路についてまとめているようです。

【前提】

1. awsアカウントは３つにわける。運用管理アカウント、本番アカウント、本番アカウント(NW管理用)
   • 運用管理アカウントは事業者が準備するっぽい
   • 本番アカウント(NW管理用)はデジタル庁側で運用・管理する感じっぽい
   • 本番アカウントはデジタル庁側から事業者に払い出される感じっぽい

【事業者側】

1. 運用管理アカウント内に構築した運用管理VPC内のサーバーからのみ、本番アカウントにログインを許可する（＝本番アクセスに少なくとも２回の認証が必要になる）
2. マネージメントコンソールへの接続はインターネット経由でいいが、運用管理VPCには専用線(Direct Connect)でのみ接続を許可する

【自治体側】

1. 接続は原則LGWANガバメントクラウド接続サービス（LGCS）からのみとなり、接続事業者からDirectConnectでの接続が提供される

上記は本番アカウント上で事業者の１つの共有サーバーに対して、各自治体が接続する方式（いわゆる普通のSaas）の形式です。その他のバリエーションとして「アカウント分離」（各自治体ごとにアカウントを分けて、専用サーバーを準備）と、「ネットワーク分離」（アカウントは１つで、各自治体ごとにVPCを割り当てて専用サーバーを準備）が記載されているようです。

Direct Connect

技術面から話をまとめてみると、Direct Connectの使い方に集約すると思います。

Direct Connectはオンプレ環境とVPCをつなげる専用線サービスです。Direct Connectを利用するときは、VPC側にVPN Gatewayを配置します。VPNを利用する場合には、VPC側にVPN Gatewayとオンプレ側にCustomer Gatewayが必要になってきます。

このことを頭に入れて、再度図を見ていきます。自治体側ではDirect Connectを利用しているのですが、よくみるとLGWANガバメントクラウド接続サービスから伸びていて、LGWAN網部分は共用のネットーワークになっています。このため、LGWAN網で他の自治体に情報が見られないようにするため、各自治体内でCustomer VPNに入り、本番アカウント(NW管理用)のVPN Gatewayで各自治体用のVPCまでVPNを張っていると思われます。同様の理由で、本番アカウント(NW管理用)⇔本番アカウントの間も仮想VPNであるPrivateLinkで接続しているようです。

逆に事業者側は各社のDirect Connectを用意するため、VPNを張る必要がなく、直接Transit Gatewayで事業者が管理するVPC群に接続している者と思われます。

参考資料

ページ中で利用しているAWSアイコンは、以下のページからダウンロードしたものを利用しています。

• AWS アーキテクチャアイコン