実話!!大型プロジェクトAWS導入 ハイブリットシステム時代のスキルと導入ポイント ~ 5年後、あなたの居場所はありますか?~
- 9. コンテンツ最新化の方法案
(1)各インスタンスが最新コンテンツを取得
コンテンツ コンテンツ
Web Web
CMS
S3最新
資材取得
最新
資材取得
コンテンツリリース
• 最新のコンテンツはストレージ領域(S3)に格納し、各インスタンスが
コンテンツを取得しに行く。
⇒AMIから新規に起動したインスタンスもコンテンツを取得することで最新化され
る。
• 各インスタンスからどのような方式でコンテンツを取得させるか検討が必要(コン
テンツリリースと同期、非同期的に定期的に確認する。など)
(2) 最新化される度にAMIを更新
• コンテンツのリリースが発生する度にAMIを更新し、新規に起動したインスタンスが最新
コンテンツの状態で起動する。
⇒コンテンツの更新頻度が高く、AMI更新中に新たなコンテンツが配置されるなどして、
静止点を設けることが難しい。
• コンテンツ資材の最新化もこの方式とする場合、新規に起動したインスタンスを検知し
て、そのインスタンスに対してもコンテンツをリリースをする作りが必要となる。
初期構築 コンテンツ更新 AutoScaling
コンテンツ
Web
AMI作成
コンテンツAMI
コンテンツ
Web
AMI更新
コンテンツAMI
コンテンツ
コンテンツ
AutoScaling
Web
新Web
- 12. セキュリティ
VPC(Virtual Private Cloud):仮想的な閉域NW空間
完全に隔離した閉域NW空間を確立し、サブネットを分割することでDMZ領域とプライベートな領域にNWを分離
SecurityGroup:ホストサーバ単位のファイアーウォール
ホストサーバ(インスタンス)毎に受信/送信に対してフィルタリングによるファイアーウォールを実施
NetworkACL:サブネット単位のファイアーウォール
NW分割されたサブネット毎に受信/送信に対してフィルタリングによるファイアーウォールを実施
データセンターネットワーク対策
DDoS(Distributed Denial of Service)対策 ▶ AWS独自のDDoS緩和対策を使用
Man In the Middle Attacks(中間者攻撃)対策 ▶ AWSリソースへのアクセス認証は全てSSLで保護
IPスプーフィング対策 ▶ AmazonがソースIPとMacアドレスの整合性をチェックし送信元を偽装したデータをネットワークに送信不可
ポートスキャン対策 ▶ インバウンドポートはデフォルトで不許可。ポートスキャンの検知、停止、ブロック対策を実施
通信の盗聴対策 ▶ プロミスキャス・モードは不許可。ハイパーバイザーレベルで制御対策実施
WAF(ウェブアプリケーションファイアーウォール)
SQLインジェクションやクロスサイトリクエストスクリプティングなどWebアプリケーションへの攻撃を防止
サーバ構成:
不要なソフトウェアのアンインストール
不要なプロセスの停止
アカウント、パスワードの適正な管理
- 14. 環境・設備
環境
設備
AWS は Tier III+ ガイドラインに従ってデータセンターを運営しています
が、柔軟にパフォーマンスを拡大および向上できるよう、Uptime Institute
の階層レベルの認証を受けないことにしています。インフラストラク
チャーのパフォーマンスに対する AWS の手法では、Uptime Institute の階
層ガイドラインを認識したうえで、それをグローバルデータセンターのイ
ンフラストラクチャーの設計に適用することで、お客様に対する最高レベ
ルのパフォーマンスと可用性を実現しています。さらに、AWS は、Uptime
Institute によって提供されるガイドラインを強化して、グローバルオペ
レーションに対応できるよう拡張しています。これにより、可用性とパ
フォーマンスについて、Uptime Institute の階層ガイドライン単独で達成で
きるレベルをはるかに超える運営上の成果を実現しています。AWS は Tier
IV への準拠を明言しているわけではありませんが、システムには自己修正
対策が組み込まれており、耐障害性の高い運営手順が整備されていること
を確約できます
※AWSの資料より抜粋
Editor's Notes
- ②のところですが、非機能要求グレードを使って整理するのが一般的です。
- AWS=個々のサービスのSLAは変えられない。マルチAZやWEBサーバの複数台構成等、その組み合わせで要件を満たす事を考える。
オンプレ=FTサーバの使用クラスタ構成等々自由度が高い。
実際の運用でも、原因不明の短時間の接続エラー等が発生する。これは原因追及が難しい事が多い。
- 増やす=サーバ作成、減らす=サーバ削除ととらえると分かりやすい。
サーバを作成した場合に、デプロイされているアプリケーションをどう最新化するかがキーとなる。
起動時のスクリプト等でS3等から最新のアプリケーションをとりにいくか、AMIイメージを常に最新化しておきそのイメージからサーバを作成する等の方式を考えておく必要がある。
- 増やす=サーバ作成、減らす=サーバ削除ととらえると分かりやすい。
サーバを作成した場合に、デプロイされているアプリケーションをどう最新化するかがキーとなる。
起動時のスクリプト等でS3等から最新のアプリケーションをとりにいくか、AMIイメージを常に最新化しておきそのイメージからサーバを作成する等の方式を考えておく必要がある。
- 監視はクラウドウオッチ使ったり、サードベンダーの監視ソフト入れたり色々できる。
オンプレだったら、サーバへ入るまでは、セキュリティルームだったり、DC入館が必要だが、その辺AWSはどうしようもない。
パスワード認証以外に、MFAデバイスの使用を検討する。
ここでは運用でおこしちゃったありがちな事例を紹介する。
- 監視はクラウドウオッチ使ったり、サードベンダーの監視ソフト入れたり色々できる。
オンプレだったら、サーバへ入るまでは、セキュリティルームだったり、DC入館が必要だが、その辺AWSはどうしようもない。
パスワード認証以外に、MFAデバイスの使用を検討する。
ここでは運用でおこしちゃったありがちな事例を紹介する。
- 増やす=サーバ作成、減らす=サーバ削除ととらえると分かりやすい。
サーバを作成した場合に、デプロイされているアプリケーションをどう最新化するかがキーとなる。
起動時のスクリプト等でS3等から最新のアプリケーションをとりにいくか、AMIイメージを常に最新化しておきそのイメージからサーバを作成する等の方式を考えておく必要がある。
- オンプレ回帰の流れもある。 はっきり言って予測できているならオンプレでよい。 不確実性、多様性に向かって柔軟に対応するならAWS。
- 5年後生き残れるエンジニアとは。 AWSとかオンプレとかはあんまり関係ないですね。 ここにいらっしゃる賢明な皆様ならお分かりかと思います。 なぜならこれらは単なるツールだからです。 「変われる事」これにつきると思います。 「経営というのは環境に適用すること」という言葉があります。 歴史を紐解けば、環境に適用できなかった、恐竜等の生物もたくさんいますし 会社・組織もたくさんあります。 エンジニアも環境に適用する事が必要です。 その時代で求められる事を察知し、取り入れ、他社(他者)と差別化する。 その為には学習して挑戦して成長して変化するというループを繰り返す事が必要です。 今日ここにきてくれた、皆さんは何かを得て変わろうとしている人達だと 思います。よって皆さんは5年後生き残れるエンジニアと私が補償します。 これまで以上に、学習して挑戦して成長し、そして変化してください。 以上ご清聴ありがとうございました。