【Report】雲勉 in 名古屋 vol.2 その１
こんばんわー！ヒサユキです。 久々のブログ投稿になりますヽ(=´▽`=)ﾉ
昨日の雲勉のレポートを書いていきます！
今回書くこと多くて1回で書くの辛いので2回に分けますｗ
雲勉については以前こちらの記事で書いたので割愛
今回の内容
『AWSでのインフラ構築におけるベストプラクティス』ということで、
クラウドコンピューティングならではの特性をオンプレとの比較と交えてのお話でした。
オンプレとは？
そもそもオンプレってなーにって話ですが、オンプレミスの略称です。
オンプレミス - Wikipedia
wikiに書いて有ることであれば、すこしニュアンスが違いますが、
ここではざっくり、物理的な固定資産のサーバだと思っていただければOKです。
こんな感じのやつ↓
AWSの提唱する10の設計原則（１〜４）
スケーラビリティ
利用頻度次第でサーバのスペックを上げるのも、サーバの台数を増やすのも自由自在！
物理サーバを購入しようと思うと、予め用途にあったスペックのサイジングがいる上に
買った時のスペックから向上させることは別途費用がかかってしまう。
また、物理サーバでは買い足すなんてのは期間がかかりすぎて現実味が薄いですよね。
クラウドなら今この瞬間、すぐ欲しいときに10分足らずで用意できちゃうんですヽ(=´▽`=)ﾉ
もちろんスペックにはさすがに上限があります。
ですが、並列稼働させられるサーバ台数はAmazonが保有しているリソースを使いたいだけ使えます。
厳密にはAmazonが保有しているだけという上限はありますが、まず普通に使っていたら上限になることはないです。
固定資産からの可処分資産へ
前項でも書きましたが、物理サーバというのは固定資産になります。
管理も必要ですし、サーバールームのようなクーラーガンガンの部屋とかを用意する必要性も出てきます。
しかも、購入は当然前払いでスペックは購入時に決めたスペックで固定ですね。
もちろん新しく追加するには１日、２日のリードタイムでは出来ません。
企業にとっては固定資産の購入になるし、かなり高い買い物になる可能性が高いので稟議とかになると思います。
その点AWSではAmazonの固定資産をリソースとして借りるイメージになるので、
個人で物理的な資産を保有する必要性がありません。
そのため停止も廃棄も簡単にできます、コンソール画面でぽちぽちっとやるだけです。
月に使用した時間に価格が乗るので、前払いの必要性もありません。
ちょっと試しにLinuxを1ヶ月ほど使いたいなら、低スペックであれば1500円程度です。
また、常時電源ONにしておく必要がないサービスなどは時間を指定して停止することも可能。
深夜帯などアクセスのほぼ無い時間は止めてしまうということも出来ます。
その場合、使った分課金のためコストダウンにつながります。
注意するのは停止した場合はIPアドレスやホスト名は開放されて、
次回起動時には 新しいIPアドレスやホスト名が付与されるため、
Elastic IPを当てて固定化するか、DNSで接続出来るような形式にしておく必要があります。
自動化
殆どのAWSの機能はAPIで動作します。
そのため、スクリプト等による自動化がしやすい仕様になっています！
また、CloudFormationを使うことで一通りのインフラをJSONファイルで書くことで、
毎回同じ形式のインフラ構成を作ることが出来ます。
これによりオペミスなどの人的ミスを減らすことが出来る上に、
作業効率の向上にも繋がります。
疎結合
システムには結合度というものがあります。
個人的には依存性と認識していますが、システムを組む構成のなかでどこかでトラブルが起きた時、
結合度が高いとシステム全体に被害が拡散します。
逆に、疎結合であるほど被害は最小限に留めることが出来ます。
そのために心がけるのが、以下の４つ。
- Well-Defined Interface
- アクセス元はアクセス先の情報を最小限にしかしらない。
- 必要な情報だけでAPIによる操作、直接的なアクセスはさせない。
- むしろサーバへも直接繋がずに、ロードバランサかSQSを間に挟む
- Service Discovery
- 増えたリソース、減ったリソースは常に検知できるようにする。
- Asynchronous Integration
- 同期処理である必要がなければ非同期で処理
- ユーザ側は同期にてアクセスブロックが掛かる心配がない
- サーバ側はフロントを停止しないで、バックエンドをメンテ出来るなどのメリット
- Graceful Failure
- リソース停止、削除、障害時のクライアントや他のリソースへの影響を最小限にするように設定しておく
AWSサービスを利用した疎結合の場合、WebサーバとAPサーバの間にELBを噛ませることで、
Webサーバがスケーリングしてもどのサーバもアクセス先はELB、
ELBはAPサーバがスケーリングしても振り分け先が増えるだけというような方法がある。
ここまでのまとめ
まずはここまで！
今回の勉強会はわりと分かる範囲の内容でした。
最近、ソリューションアーキテクトの勉強もしているのでほぼほぼ解る言葉ばかりだったので、
こうやってブログでまとめていても、結構しっくり来ています！
書くボリュームが多いので今日はここまでにしますが、
続きはできれば明日にでも書きますヽ(=´▽`=)ﾉ
