【AWS】OpsWorks スタック

はじめに

タダです。
AWS認定資格の試験勉強のためにCloudFormationの情報をまとめた自分用メモになります。
あくまで個人用のメモになるので、その点はご了承ください。
※違う内容書いているなどありましたらご指摘いただけると幸いです。
※随時アップデートがあれば更新していきます。
※本記事では、OpsWorks スタック中心のまとめになります。

サービス概要

  • OpsWorksはChefを使ったAWSリソース(EC2、ELB、RDSなど)やEC2上のアプリケーションの設定・管理を行うためのサービス
  • Chefサーバーは不要で、OpsWorksスタックは、インスタンスのヘルスチェックをモニタリングし、自動復旧および Auto Scaling を使用して、必要な場合に新しいインスタンスをプロビジョニングする
  • Chefのcookbookレシピを使って、インフラの管理を自動化、アプリケーションの継続的なインストール、構成、管理、デプロイ、スケールが可能なのがChef Automate
    • Chefサーバありきだが、管理はAWS

OpsWorksエージェント

  • OpsWorksスタックで必要

    • OpsWorksの一連のコマンドを取得し、エージェントがChef Clientのローカルモードでレシピを実行

利用メリット

アプリケーションのモデル化とサポート
管理作業を自動化

CloudFormation/Elastic Beastalkとの違い

  • OpsWorksは、DevOps環境を提供することを目的におき、デプロイ、モニタリング、自動スケーリング、自動化の主要なアクティビティに対して統一された設定管理を行う
  • CloudFormationはAWSリソースのプロビジョニングと管理をJSON/YAMLで行うことを目的とする
  • Elastic BeastalkはJava、.NET、PHP、Node.js、Python、Ruby、Go、Docker で開発されたウェブアプリケーションとウェブサービスをデプロイおよびスケーリングする

制限

デフォルトでは、最大40スタックを作成できる
最大40のレイヤー、最大40のインスタンス、最大40のアプリケーションを保持できる
 

専門用語

  • スタック

    • OpsWorksの管理対象をまとめたコンポーネントで、属する全員インスタンスの構成を管理する
  • レイヤー
    • 1つ以上の Layer を追加することにより、スタックのコンポーネントを定義する
    • レイヤーは、アプリケーションへのサービス提供やデータベースサーバーのホストのような特定の目的を果たす一連のEC2インスタンスを表す
  • インスタンス
    • インスタンスのスケーリングタイプは3つある

      • 24/7インスタンス(常時稼働)
      • load-basedインスタンス
        • 負荷に対してサーバを起動することができる
        • メトリックスの閾値は次のものを定義し、インスタンスの増減をコントールできる
          • [Average CPU] – Layer の平均 CPU 使用率 (合計に対する割合)
          • [Average memory] – Layer の平均メモリ使用率 (合計に対する割合)
          • [Average load] – Layer の平均負荷
      • time-basedインスタンス
        • 時間ベースのスケーリングにより指定したスケジュールでインスタンスを起動、停止できる
        • 特定の時間または特定の曜日にレイヤーによりオンラインにされるインスタンス数を制御できる
  • App
    • アプリケーショサーバにデプロイするアプリケーション
  • レシピ
    • Chefレシピを実行して、アプリケーションの設定、アプリケーションのデプロイ、スクリプトの実行などを行う

スタックコマンド

スタック全体の構成を変更・管理するためのコマンドで以下のようなものがある
実行方法はAWSマネジメントコンソールやCLI、SDKなど

  • Update Custom Cookbook

    • リポジトリにある更新されたCookbookをそれぞれのインスタンスに展開する
  • Execute Recipes
    • 指定したレシピを指定したインスタンス上で実行する
  • Setup
    • Setupのレシピを実行する
  • Configure
    • Configureのレシピを実行する
  • Upgrade Operationg System
    • (Linuxのみ)Amazon Linuxを最新バージョンにアップグレードする

ライフサイクル

OpsWorksのインスタンスで自動的に行う処理をさす

  • Setup : 新しいインスタンスが正常にブートした後に発生する

    • ex: ロードバランサーをインストール、アプリケーションサーバをインストール、データベースをインストール
  • Configure : インスタンスがオンライン状態に移行したときとオンライン状態から移行した時にスタックのすべてのインスタンスで発生する
    • ex: アプリケーションサーバのIPをアップデート、DB接続先をアップデートして再起動、アプリケーションサーバのIPのACLをアップデート
  • Deploy : ユーザーがアプリケーションをデプロイする時に発生する
    • ex:アプリケーションコードをアップデートして再起動
  • Undeploy : アプリケーションを削除する時に発生する
    • ex:アプリケーションを削除して再起動
  • Shutdown : インスタンスの終了
    • コネクションをDrainする、ログを保存、スナップショットの保存

Opsworksと他サービスとの連携

モニタリング

スタックは次の方法で監視可能

  • CloudWatchによるスタックのインスタンスごとに詳細モニタリング
  • CloudTrailによるAPI監視
  • CloudWatch Logsでスタックのシステム・アプリケーション・カスタムログを監視する

セキュリティおよびアクセス許可

  • VPC内に展開可能
  • AWSリソースにアクセスするためのACLやインスタンスへの接続管理はIAM(ユーザー、許可、ロール)で行う

参考

更新日時

  • 2017/05/01 初回投稿

続きを読む

AWS上でMongoDBを動かす

MongoDBに関する基本的な内容をまとめてみたものです。MongoDBに関する、Web上にすでにある良識な解説コンテンツをまとめたまとめサイトの抜粋です。
AWS上でMongoDBを動かす

AWSであれば、MongoDB環境を容易に構築できる

AWS MarketPlaceには、MongoDB環境を構築するために必要なミドルウェアがプリインストールされたOSイメージが多数あります。
※MongoDBの開発元である 10gen (現MongoDB Inc.)もMongoDB入りイメージを無償提供中

基本的に、それらのイメージをもとにAWSのインスタンスを立ち上げればMongoDB環境ができあがります。英文ですが、下記に具体的な構築手順があります。
http://www.mongodb.org/display/DOCS/AWS+Marketplace

AWSの複数ゾーンとレプリカを組み合わせればDRも容易

MongoDBは、マスタ/スレープ方式のレプリケーションに対応しています。

世界中のデータセンターから選択できる、AWSのさまざまなリージョンやアベイラビリティゾーンを複数選択してMongoDBのレプリカ機能を使用すれば、DR (Disaster Recovery)対応も可能です。

AWSは12のリージョンに、合計で33のアベイラビリティゾーンで運用されています (2016年5月現在)
https://aws.amazon.com/jp/about-aws/global-infrastructure/
AWSのリージョンは、最低でも2つのAZ(アベイラビリティゾーン)をもっていて、それぞれのAZはお互いに地理的・電源的・ネットワーク的に分離されつつも、AZ間は高速専用線で接続されています。

一方のゾーンにMongoDBおよびMongoDBのArbiterインスタンスを立ち上げ、もう一方のゾーンにMongoDBインスタンスを立ち上げれば、片方のゾーンで地震等の災害があっても、データが残り、そのままMongoDBは機能し続けます。

シャードとレプリカを組み合わせたMongoDBクラスタ構成

MongoDBでは、基本的に、シャードを増やすことにより水平スケールさせ、レプリカにより可用性を実現します。各シャードをレプリカセットにすることにより、高い可用性を実現しながら、水平スケールさせた大規模なデータベースを構成することができます。

開発段階では、1 つのレプリカセットから始めることもできますし、本稼働中に 3 つのレプリカセットに移行することもできます。下記URLに、AWS上でMongoDB環境を構築するアーキテクチャ例が示されています。
http://docs.aws.amazon.com/ja_jp/quickstart/latest/mongodb/architecture.html
・図1: レプリケーション係数 3 の MongoDB リファレンスデプロイ
・図2: 3つのレプリカセット2方向シャーディングを使用するAWSのMongoDBクラスター

MongoDBをAWS上で動くようにするまでの手順

AWSにて、MongoDBを動くようにするまでの手順は、概略、下記の通り:

・EC2インスタンスおよびEBSボリュームを用意

・Amazon VPC をセットアップ

*Amazon VPC 内のプライベートサブネットとパブリックサブネット、NAT インスタンス、
セキュリティ グループ、IAM ロールなど、MongoDB のデプロイ中に必要な様々な
ネットワークリソースを作成

・Amazon EBS をセットアップして MongoDB を保存。

・MongoDB 設定をカスタマイズするオプションを指定した後、MongoDBを起動。

MongoDB のバージョン番号 (2.6 または 3.0)、レプリカセットの数 (1 または 3)、シャード数
(0、1、2、または 3)、インスタンスあたりのマイクロシャード数を選択することができます。

※より詳細は、下記を参照ください。
[AWS上の MongoDB] http://docs.aws.amazon.com/ja_jp/quickstart/latest/mongodb/deployment.html

続きを読む

MongoDBのアーキテクチャ

MongoDBに関する基本的な内容をまとめてみたものです。MongoDBに関する、Web上にすでにある良識な解説コンテンツをまとめたまとめサイトの抜粋です。
MongoDBのアーキテクチャ

MongoDBにおけるクラスタ構成

MongoDBでは、レプリケーション機能・シャーディング機能を提供しており、両者を組み合わせることにより分散コンピューティング環境にて、負荷分散された冗長構成のクラスタを構築することができます。
(アプリケーション側からは、クラスタ全体をひとつの論理DBとみなすことができます)

・レプリケーション構成においては、一般的な条件下では障害からの自動フェイルオーバー
・シャーディング構成においては、自動バランシング機能を備え、データをそれぞれのノードにできるだけ均等に配分するとともに、動的にノードの追加や削除にも対応

クラスタ構成要素
– primaryサーバ レプリケーションのマスタ。データのマスタを保持
– secondaryサーバ レプリケーションのテレーブ。プライマリ上のデータのコピーを保持
– arbiterサーバ 自動的にフェイルオーバーする際に新しいプライマリノードを選択・指示
– configサーバ シャーディングの構成情報や分散状況を保持
– mongosサーバ シャーディング構成にて、データリクエストに対するルーティングを実施

2方向シャーディングと3レプリカセットのクラスター

MongoDBで、レプリケーション・シャーディング機能を利用して、可用性と水平スケールを実現する構成を実現する場合、最小構成で2方向シャーディングと3つのレプリカセットの構成となります。

MongoDBでは、ひとつのレプリカセットから始めて、本稼働中に3つのレプリカセットに移行することも可能です。

複数のレプリカ構成の場合には、書き込みオペレーションはプライマリノードで行われ、セカンダリノードに非同期にレプリケートされます (読み取りオペレーションでセカンダリノードを選択する場合には、古いノードに注意する必要があります)

MongoDBでは各シャードをレプリカセットにすることができます。2方向シャーディングと3つのレプリカセットの構成の場合には、ひとつのシャードが3つのレプリカセットにレプリケートされます。
AWSを利用する場合には、それぞれのレプリカは別々のアベイラビリティーゾーンに格納されますので、データセンター単位での障害があった場合でも、別のアベイラビリティゾーンにあるレプリカに自動フェールオーバーされてMongoDBは機能し続けることができます。

※参考: MongoDB on AWS >> アーキテクチャ
http://docs.aws.amazon.com/ja_jp/quickstart/latest/mongodb/architecture.html

続きを読む

MongoDB – OOS ドキュメント指向 noSQL DB

MongoDBに関する基本的な内容をまとめてみたものです。MongoDBに関する、Web上にすでにある良識な解説コンテンツをまとめたサイトの抜粋です。
MongoDB – OOS ドキュメント指向 noSQL DB

結果整合性保証モデルとし、高い可用性と水平スケールを実現

MongoDBは、「結果整合性」しか保証しないことにより、水平スケールさせることを目指した、分散コンピューティング環境にマッチしたデータベース。

結果整合性:
誰かがデータを更新し、そのデータが複製されるのに十分な時間が過ぎ、その後更新が加えられなければ、必ずその新しいデータにアクセスできる

つまり、MongoDBでは、データの更新リクエストが完了しても、分散環境にコピーされている全データの更新が終了しているとは限らず、そのタイミングで外部からデータ読み込みをすると、更新後のデータを読み出せるとは限りません。

従って、MongoDBでは、トランザクション処理を行わせることはできません。また、テーブルのJOIN操作もできません (複数のドキュメントをDB側で結合できない)。

しかし、この完全には一貫性を保証しないという割り切りは、RDBSでは実現することが難しいレベルでの水平スケールを可能とするだけでなく、複数のデータコピーを持たせることも容易にし、高い可用性も実現します。

ドキュメント指向のデータベース

MongoDBは、ドキュメント指向のデータベースであり、スキーマレス。つまり、あらかじめ定義された型にデータを登録するのではなく、さまざまな型のデータをそのまま登録していくことが可能です。

MongoDBでは、以下の概念でデータを操作します。

・DB (データベース)
・コレクション (Collection)
・ドキュメント (Document = Object)

「ドキュメント」と呼ばれる構造的データをJSONライクな形式で表現し、そのドキュメントの集合を「コレクション」として管理します(RDBのテーブルに対応)。コレクションはRDBMSのような固定的なスキーマを持ちません。ドキュメントには複雑な階層構造を持たせることもでき、それらの構造に含まれるフィールドを指定したクエリやインデクス生成も簡単な指定によって行えます。

RDBMSのように高度な結合操作を効率的に行うことはできませんが、データの追加・更新・削除・クエリは高速に行うことができます。

なお、MongoDBはスキーマを定義しなくてもよいのですが、パフォーマンス面を考えると、スキーマを定義することが多く、作りながらスキーマを定義・修正していくという柔軟な開発を可能とするデータベースといえます。

noSQLでありながら、多彩なクエリに対応

Mongoクエリ言語という、SQLライクな操作言語によりデータベースにアクセスします。

データ構造がDB -> コレクション -> Documentとなっていて、取り扱うDocumentデータがJSON形式のデータとはなりますが、JOINを除く、ほとんどのSQLを再現することができます。

また、変数・制御構造なども記述することができますので、集計等の高度なクエリも記述することが可能です。

[制御構造を使用した例]
MongoDBでは、JavaScriptの制御構造を使用することができます。たとえば、以下のようにforループでデータを挿入することができます。
for (var i = 1; i <= 20; i++) db.col1.insert( { x : 4 , j : i } )

レプリカセット: 高い可用性を実現できる仕組み

MongoDBは、マスタ/スレープ方式のレプリケーションに対応しています。簡単な仕組みで高可用性を実現することができます。

MongoDBではマスターのことをプライマリ,スレーブのことをセカンダリと呼びます。セカンダリは,プライマリのデータのコピーを保持します。レプリケーション構成としておけば、マスターノードに障害が起きても、自動フェイルオーバーの機能がありますので、データロストやサービス停止期間を最小にすることが可能です。MongoDBのレプリケーションの最小構成は,3つのノードが必要です。

また、レプリケーションを使用すれば,読み取り(Read)の負荷をノード間で分散させることができます。負荷のほとんどがReadで占められているようなアプリケーションの場合,Readの負荷をスレーブに分散させることによりシステムをスケールさせることが可能です。

オートシャーディング: DBデータを水平スケールさせる

シャーディングとは,データを複数のサーバに分散させる機能です。データを複数のサーバに分散させることにより,CPUやI/O負荷を分散させることが可能となります。

シャード:
実際にデータが格納されているmongodプロセス。1つのドキュメントは1つのシャードに格納され,シャード間でデータの複製は行わない

MongoDBのシャーディングはレンジパーティション方式を採用しています。シャードキーを指定することで,各サーバに格納されるデータの範囲が決定されます。サーバ間で重複データは持たず,1つのデータが格納されるサーバはシャードキーの範囲によって1つに決定されます。

キー範囲の調整と,調整に伴うサーバ間のデータの移動まで全部MongoDBが行う自動バランシングという機能を備えています。自動バランシングにより,サーバ間のデータの偏りをユーザが意識しなくてもよいように設計されています。また,新たにサーバを追加した場合も,同様にデータの移動を行い偏りがなくなるように自動調整します。

MongoDBを構成するコンポーネント

MongoDBは、マスタ/スレーブ方式のレプリケーション機能をもっていますが、MongoDBは自動フェイルオーバーを実装しており、マスタに障害が発生しても自動的にフェイルオーバーとリカバリが可能です。そのための構成要素として、MongoDBでは、マスターである「プライマリ」、フレーブである「セカンダリ」およびフェイルオーバーの際に新しいプライマリノードを選択する役割をはたす「アービター」というコンポーネントがあります。セカンダリは、プライマリのデータのコピーを保持し、アービターはデータのコピーは保持しません。自動的にフェイルオーバーするレプリカセットを構成するためには、最低でも三つのノードが必要となります。

プライマリ: レプリケーションのマスタ。データのマスタを保持

セカンダリ: レプリケーションのスレーブ。プライマリ上のデータのコピーを保持

アービター: 自動的にフェイルオーバーする際に新しいプライマリノードを選択

MongoDBのシャーディングはサーバ間のデータの移動を自動で行う自動バランシングの機能を備えていますが、そのデータ管理を行うために、configサーバとmongosサーバというコンポーネントがあります。

configサーバ:
シャーディングのメタデータを管理しているmongodプロセスです。単一障害点となるので,複数のconfigサーバで構成することが推奨されています。

mongosサーバ:
シャーディングにおけるルーティングプロセスです。シャードとクライアントを連携させます。必要があれば複数のmongosサーバをたてることが可能です。

続きを読む

NATゲートウェイの設定 / AWSのプライベートサブネットから、インターネットに接続する

◆ 今日やること

AWSのプライベートサブネットから、インターネットに接続する場合、NATゲートウェイが必要です。
プライベートサブネットに配置したEC2インスタンスからyum installとか実行する時に必要ですよね。

NATゲートウェイの設定がないと、インターネットに出て行けません。


$ sudo yum install -y mongodb-org
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main/latest                                                                          | 2.1 kB     00:00
amzn-updates/latest                                                                       | 2.3 kB     00:00
https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/repodata/repomd.xml: [Errno 12] Timeout on https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/repodata/repomd.xml: (28, 'Connection timed out after 30000 milliseconds')
Trying other mirror.

failure: repodata/repomd.xml from mongodb-org-3.2: [Errno 256] No more mirrors to try.

◆ 実装編

> NATゲートウェイの作成

サブネットの選択は、Publicサブネットにしましょう

NATゲートウェイの作成.png

> ルートテーブルの設定をします

0.0.0.0/0の送信先ターゲットを上記で作成したNATテーブルに変更します。

ルートテーブル.png

> 確認

AWSのプライベートサブネットから、インターネットに接続できるようになったかと思います。
以下を実行して、インストールが完了すればOKです。


$ sudo yum install -y mongodb-org

続きを読む