「AWSの思想」は色々勉強になるので、インフラエンジニアは必読だ
インフラエンジニアとして外せないのはクラウドですよね。 そのクラウドの頂点に立っている「Amazon Web Service」こと「AWS」ですが、 AWSは色々な考え方があって、その考え方はエンジニアの人にはいろいろ為になるなーと思ったので、3つほど紹介したいと思います。
あ、別に「AWSの思想」みたいなまとめられたものがあるのではなく、AWSのこと勉強してたらだいたこんな感じの思想なんだなってものをまとめたものになります。
サーバーは停止するから、可用性を考えた作りにしよう
AWSにとっては、「サーバーは止まるもの」という考え方があります。 AWSを使っている方であれば、「インスタンスはこの日に強制で再起動するよ」みたいなものを見たことがあると思います。
そういったことを考慮して、サーバーが1台落ちてもサービスは止まらないような設計を考えるべきだとAWSは言っています。 これはオンプレミス環境であっても同じで、たった1台で運用していて、そのサーバーが落ちてしまったら終わりですよね。
「サーバーが落ちる=サービスが止まる」ということにしてしまわないように、可用性を考えた作りにしましょう。
これをAWSでは「Design for Failure」といいます。
Design For Failure – 基本原則 単一障害点（single points of failure）の排除 全てが故障すると仮定して、保守的に設計する Goal: 物理ハードウェアが故障して、消失したり交換されてもアプリケーションは機能する 障害からの復旧を計画する ビジネスニーズと高可用性実現コストのトレードオフ
Webサーバが落ちても止まらないようにELB配下に2台構成にする、などですね。
それぞれのサービスのレベル
AWSにはたくさんのサービスがあります。EC2、RDS、Route53、S3…
そのサービスには「サービスのレベル」というものが決まっています。 サービスのレベルの名前と、そのサービスレベルにある主なサービスを紹介します。
| 名前 | 主なサービス | どんなものか |
|---|---|---|
| インフラストラクチャサービス | EC2、EBS、VPC、Auto Scalling | IaaS相当。仮想サーバなど、オンプレミス環境に近いものをユーザーが管理 |
| コンテナーサービス | RDS、EMR、Elastic Beanstalk | PaaS相当。OSレベルの管理はすることがなく、アプリケーションをユーザーが管理 |
| 抽象化サービス | S3、DynamoDB、SQS、SES | SaaS相当。OSレベル、アプリケーションもAWSが完全に管理し、ユーザーは対象のサービスを使うのみ |
例えばEC2は、自分でサーバーを作ったりして、OSの設計などハードウェア以外の全てを設計する必要がありますが、 RDSの場合は、既にOSに乗っているDBまでは用意されているので、 そこに乗るデータベースのことだけを考えたらOKで、OS、ハードウェアのことはAWSが管理してくれます。
「EC2の場合はハードウェアはAWSが管理、RDSの場合はOS、ハードウェアはAWSが管理」これが次の重要な考え方に繋がります。
責任共有モデル
AWSはクラウドですが、もちろん「AWSのデータセンターにあるサーバ」に仮想サーバを立てて使っています。 そのサーバーの責任は「誰がどの部分」を負うのか？というのがこの「責任共有モデル」です。
EC2サービス（インフラストラクチャサービス）の場合を考えてみます。
レイヤーを分けてみると、こんな感じになると思います。 （細かく分けるともっとでますが、ざっくりと）
【1.OS】
- アプリケーション
- ミドルウェアのインストール・設定
- OSのインストール・設定
【2.AWSの設定】
- セキュリティグループの設定
- EC2のネットワークの設定
- バックアップの設定
【3.AWSのデータセンター】
- 仮想サーバの基盤保守運用
- ネットワークインフラ保守運用
- ハードウェアの物理的なセキュリティ（侵入など）
責任共有モデルはこの部分で「どこがユーザーが責任を持って設定・運用するか」「どこがAWSが責任を持って設定・運用するか」です。
この場合は1.2.はユーザが責任を持って設定する部分です。 例えば、セキュリティグループ（AWSのF/W）の設定をユーザが全開放にしていて、もし外部から攻撃を受けたとしても、それはユーザーの責任、となります。 逆に、3.のところでAWSのデータセンターに侵入されてデータを盗られた、なんてことになるとAWS側の責任になります。
このように、お互いに責任を担保しながらやっていきましょう、というのが責任共有モデルという考え方です。
AWSのセキュリティベストプラクティスから引用します。
AWS が安全なインフラストラクチャとサービスを提供する一方で、お客様には安全なオペレーティングシステム、プラットフォーム、データを用意する責任を負います。AWS は安全なグローバルインフラストラクチャを確保するためにインフラストラクチャコンポーネントを構成し、お客様がセキュリティの強化に利用で きるサービスと機能を提供します。
引用：AWSセキュリティベストプラクティス（PDFが開きます）
コンテナーサービスの場合は、RDSで考えると、「OSの設定」と「ミドルウェアのインストール」まではAWS側が管理してくれるので、データベースのチューニングや、おくべきデータについて考えればOKになります。
更に抽象化サービスについては、全てがサービス化されているので、SESだとどういうメールアドレスが必要なのか？などを考えればOKなのです。それ以外は全てAWSが責任を持って管理をします。
まとめ
AWSの考え方を紹介しました。 AWSは「インフラはAWSに任せて、サービスのこだけ考えてね！！」ということが考え方の根底にあります。 （インフラエンジニアにとっては怖い言葉ですが）
ただ、「責任共有モデル」などは、インフラとサービス（フロント）を切り分けたときに大事な考え方になってくると思います。
おあとがよろしいようで。