内容
オンプレで設計する場合とAWSで設計する場合は当然、実装方法は異なりますが考える切り口は同じかと思います。そう考えると今までAWSをやったことがなくても、オンプレの経験があればスムーズに入っていけるんではないか、というのがこの記事の全体的な内容となっております。
例
シンプルに下記仮想サーバを1台だけ構築する場合を考えます。
※単純にするためネットワークの部分は省きます。
要件を考える
非機能要件の可用性の箇所を考えてみると
考えるポイントはオンプレの時とあまりかわりませんね。
- 壊れることをどう検知するか
- サーバが壊れたらどうするか
- 壊れたあと復旧をどうするか
- DRをどうするか
- (シングル構成としているので冗長化は考えていない)
補足
上記は超ざっくり記載しているだけで業務では非機能要求グレードなどのフレームワークを利用してもれなく要件を洗い出したりします。このあたり、IPAが出しているので情報処理技術者試験を勉強しているうちに少し勘所がつかめるかと思います。
ちなみ要件がありそこからクラウド、オンプレを決めるパターン、クラウドありきの要件パターンなどまちまちです。
設計を考える
オンプレだと、ハードが壊れたらどうするか、ハイパーバイザー以下で問題があったらvMotionで動かしましょうのような感じですが、AWSでも同様です。ハードが壊れたらAWS側で対応、ハイパーバイザー以下で問題があったらインスタンス自動復旧などで対応します。
この場合の責任範囲は下記のようにないます。詳しくは責任共有モデルの中でどの範囲をユーザ側でやって、どの範囲をAWSがやるかの定義があります。
| レイヤー | オンプレ | AWS |
|---|---|---|
| ハードウェア | ユーザ | AWS |
| ハイパーバイザー | ユーザ | AWS |
| 仮想マシン | ユーザ | ユーザ |
あと、AWS側で対応してくれる箇所は特に考えなくてもよいですが、この範囲はAWS側の責任であると設計がされたと認識を持つことが重要です。
まとめ
- 要件定義フェーズで考えるべきポイントは似ている
- (※当然クラウド特有の箇所もあり)
- 設計・実装方法、責任範囲が異なる
上記よりAWS機能の学習とクラウドに特化した設計手法の学習ことが重要だと考えています。
AWS機能の学習はAWS認定資格を通して、設計手法はWell-Architectedで学習しました。
これからインフラ技術の基礎やAWSの基礎などを勉強したい人向けに勉強会を開催します。
オンライン開催ですのでお気軽に参加下さい。