1. AWSについてのまとめ

    あけましておめでとうございます。

    今年はもう少し更新頻度をあげて、内容も充実させていければと思います。

    さて、何かと話題で勢いのあるAWSについて調べたのでまとめておきます。



    AWSとはAmazon Web Servicesの略でアマゾンが提供するクラウドサービスでIaaSの世界で最も影響力があり、シェアNo.1となっているらしいです。

    前回のインフラエンジニアの回でも触れましたが、クラウドとはインターネット経由で提供されるコンピュータ資源を利用する、というものです。

    まずはクラウドのおさらいを。

    特徴


    • 自社で物理サーバを持たずに使えるため、物理サーバを管理するエンジニアが不要

    • 利用申請後、短期間でOSがインストールされた状態ですぐに使える

    • 物理的制約を意識せず、利用したい分だけサーバ増強が可能

    • 使った分だけ費用が発生

    • 資産を持たずに済むので、減価償却処理が不要


    弱点

    • 通常は用いられないような大量のハードウェアリソースを求めるようなスケールアップには弱い

    • 物理サーバの管理をクラウドベンダーが担うため、物理サーバに障害が発生した場合、クラウドベンダーからの復旧完了通知を待つしかない

    • クラウドベンダーの手違いでデータが消えるリスクがある


    クラウドに向かない用途

    • 機密情報を置く

    • 大容量のファイル転送

    • 大規模システム


    という感じでしょうか。他には、毎月に支払う一定額分がすべて費用処理化できるため、資金的余裕がない場合に資金繰りが楽になる、というような会計処理でのメリットもあります。

    オンラインゲームなどリリースしてみないとどの程度アクセスがあるかわからない場合、リリース後にインスタンス数を増減させて適正規模に調整するような運用が可能となるので非常に効率的ではないでしょうか。

    クラウドについてはこんなところであとはAWSの主なサービス、気になった機能などを。

     

    EC2

    Amazon Elastic Computing Cloudの略。


    Amazonの管理するデータセンター上に仮想化されたWebサーバを構築し、自らの開発したソフトウェアを自由に実行することができるサービスで、使用時間や外部へ送信されたデータ量に応じて課金される。


     

    RDS

    Relational Database Serviceの略。


    クラウドでのリレーショナルデータベースのセットアップ、運用、およびスケーリングを容易に行えるようにするウェブサービス。


    既存のデータベースで現在すでに使用しているコード、アプリケーション、およびツールはそのままでデータベースの管理タスクをamazonがやってくれるというもの。


    昨年11月?PostgreSQLをサポートし、MySQL、Oracle、Microsoft SQL Server、PostgreSQLが使用できる。


    RDSの注意点

    ・SSH(RDP)接続ができない

    RDSが稼働しているOSにEC2インスタンスと同様にSSHやRDPで接続しても、ログインは不可能。


    AWSの仕様として、RDSが動作するOSへのアクセスはできないようになっている。


    ・IPアドレスを固定できない

    エンドポイントにひも付いているIPアドレスは変更される可能性があるため、アプリケーションやミドルウェアからのDB接続先はエンドポイント名にする。


    ・タイムゾーンが変更できない

    RDSのタイムゾーンが協定世界時(UTC)で固定されているため、日本時間にするにはDBへのセッションごとにタイムゾーンを宣言する設定にしないといけない。


    ・スナップショットからRDSを作成できない

    RDSのインスタンス名が既に存在している場合に作成できない。


    回避するには既存のインスタンス名と重複しないように名前を変更すればよいが、アプリケーションやミドルウェアの設定も変更する必要がある。


    ・スナップショットが作成できない

    RDSを起動する際のオプション「Automatic Backups」を有効にしないと手動でもスナップショットが取得できなくなる。


     

    メール送信サービス

    Amazon SES (Amazon Simple Email Service)


    バルクメール送信サービス。


    信頼性が高くスケーラブルなインフラストラクチャ上に構築された、コスト効率の良いメール送信サービス。


    トランザクションメールやマーケティングメッセージ、その他あらゆる種類の高品質なコンテンツを送信できる。


    送信の統計に簡単かつリアルタイムでアクセスできるほか、バウンスや苦情に関する通知機能を内蔵している。


    送信されたメール数、データ転送料、添付ファイルに対する従量課金制。


    通常、大規模なメールソリューションを構築することは複雑で困難。メールサーバーの管理やネットワーク構成、IPアドレスの評価といったインフラストラクチャ上の課題に対処する必要があるが、それら一切をamazonがやってくれる。


     

    Auto Scaling

    定義した条件に応じて、Amazon EC2の能力を、自動的に縮小・拡張することができる。


    インスタンスの数を需要が急上昇した時はシームレスに増やしてパフォーマンスを維持し、需要が落ち着いてきた時に自動的に減らすことにより、コストを最小化する。


    使用量が時間、日、週ごとに変化するアプリケーションに最適。


    Amazon CloudWatch で有効にすることができ、Amazon CloudWatch の料金を超える追加料金は発生しない。


     

    ロードバランサ

    ELB (Elastic Load Balancing)


    複数の Amazon EC2 インスタンス間で、アプリケーショントラフィックの負荷を自動的に分散する。


    アプリケーションの高いレベルの耐障害性の実現を可能にし、アプリケーショントラフィックの分散に必要な負荷分散容量をシームレスに提供する。


    アプリケーショントラフィックの要求を満たすように、要求処理容量を自動的に縮小/拡大。さらに、Auto Scalingと統合して、手動の介入を必要とせずに、さまざまなトラフィックレベルを満たすバックエンド容量を確保。


    ・セッション


    ロードバランサ適用時にセッションが維持されるのかよくわからなかったんですが、2010年にSticky Sessionに対応しているみたいです。(各セッション(クライアント)の初めてのリクエストが来た場合に「どこへ割り振ったか」の情報も cookie などで一緒に返す機能。二回目以降のリクエストは前回と同じところへ割り振られる。)


    他にもS3(ストレージ)やCloudWatch(監視)などたくさんのサービスが提供されていますがこのへんでやめておきます。日本語サイトも充実しているので助かります。

     

    感想

    使いたいときに使う分だけ利用できる、というのは資金力のない個人または企業やスタートアップには最適で、圧倒的にメリットが大きいと思います。デメリット面でのよほどのネックがない限りAWSに限らずともクラウドを使わない手はないな、という感じです。

    クライアントサイドで何でもできるようになってきているので、サーバー側の面倒なインフラ面や金額的なリスクを(あまり)考えずに開発できるのは素晴らしいですね。年々、プログラミングの敷居が下がっている気がするので(僕もそれで始めたようなもんです)アイデアさえあれば気軽に試せるこんな環境はどんどん面白いサービスが出てくる気がしてワクワクします。

     

     

    今回見させていただいた主なサイトのリンク集です

    AWS RDS 公式

    RDS つまづきポイント

    Amazon RDSを使ってみた

    Amazon Simple Email Service(Amazon SES)公式

    Amazon SESでメール配信を行う

    Auto Scaling 公式

    手順 9: Auto Scaling を使用して Amazon EC2 インスタンスを起動する 公式

    AWSのVPCでAuto Scalingを試した記録

    ELB 公式

    AWS ELBを用いたサーバーの冗長化を行う方法

    AWS ELBを用いたサーバーの冗長化を行う方法

    訳:ELB:評価方法のベストプラクティス

    Amazon Web Servicesについて

    AWS Amazon EC2 + Amazon RDSを使ってWordPressを構築する

     

     

     

    Posted by Shunsuke Hayashi on 2014年01月04日
    Categories AWS