読者です 読者をやめる 読者になる 読者になる

Azureについての備忘録

Azureについて調べたメモ。

テンプレートをいじる

AWSでCloudFormationをいじっているので、Azureでの類似機能であるResource Managerを軽く触れてみた。

結論として、AWSほど多くのことをテンプレートでカバーできるかが怪しいという印象、コードでインフラをするのであればJSONではなくPowerShellをカタカタした方がいいと感じた。

VirtualMachine主体の構造

AWSでは、VPCをまず配置し、サブネット及びAZを決定したうえでEC2を配置する考え方だけど、

Azureではまずは仮想マシン(VirtualMachine)を配置し、その仮想マシンが所属するネットワークやサブネットの情報はあくまで一要素に過ぎないような考え方になってる。

リソースコンポーネントが細かい

AWSのEC2では、ストレージやネットワーク情報はEC2リソース情報に過ぎないけど、Azureではストレージ及びNICそれぞれが仮想マシンと並んで一つのリソースとして扱われる。

作成順序に気を使う必要あり

AWSではテンプレートからのデプロイ時の各コンポーネントの作成は自動的に矛盾がない順序で行われたが、Azureでは作成者が気を使う必要あり。

※dependsOn関数とReference関数

例えば、仮想マシンAにストレージBを付ける、と定義する際にストレージBが存在しないのに仮想マシンAを作成しようとしても仮想マシンAからすればBが何のことだか分からない。そのため、dependsOn関数もしくはReference関数であらかじめBを宣言しておく必要がある。

 

vNET間を接続する

vNET (VPC)間を接続する際に参考になりそうなものをメモ

www.rem-system.com

 

docs.microsoft.com

Route53が気になったので調べた。

AWSのRoute 53の機能が気になったので調べてみた。

 

気になった機能

ALIASレコード

CNAMEレコードと似ている。

CNAMEレコードとは、あるホストの名前解決を別の名前へ挿げ替えることが可能。例えば「www.abc.com」のDNSクエリがあった場合に「www.def.com」へ転送することができる。

ただし、CNAMEレコードでできないこととして、Zone Apex (あるドメインの頂点、例えばabc.comなど)を転送元として設定ができない。

ALIASコードはそれが可能であることが特徴。

AWSの各サービスのエンドポイントの名前解決に利用できる。

 

加重ルーティング

レコードセット(名前とIPアドレスの組み合わせ)に重みを付けて、ルーティング先の頻度を決定できる。

 

レイテンシールーティング

クライアント端末からAWSリージョンへのレイテンシが最小のエンドポイントを選択して、ルーティングさせる。

 

フェールオーバールーティング

ヘルスチェックと組み合わせ、名前解決によりアクティブ/パッシブフェールオーバーを実現できる。

TCPレベル、HTTP/HTTPSレベルのモニタリングが可能。

 

(例)こんなことが可能

f:id:no1497:20170416000237j:plain

 

AWS Black Belt Tech シリーズ 2016 - Amazon Route 53より

 

上記のような複雑な設定を行うのに、トラフィックフローのインタフェースを使ってGUIベースで設定が可能。

 

トラフィックフローはこんなの↓

f:id:no1497:20170416000814p:plain

Amazon Web Services ブログ: 【AWS発表】Amazon Route53 トラフィックフローより

 

いじってみよ。

CloudFormationをいじる ELB基礎編

今日はELBをいじった。

CloudFormation楽しい。

 

参考記事はこちら。

docs.aws.amazon.com

 

テンプレ例

f:id:no1497:20170411235015j:plain

 

今回はこれを作ります。ELB意外は前回と同じ要領。

例によって最低限の構成テンプレ。

ELBテンプレ

HTTP(TCP/80)で待ち受け、登録インスタンスへHTTP(TCP/80)で配布するELB:"ELB1"を作成

ELB1はセキュリティグループ:"SecurityGroup2"に属し、サブネット:"Subnet2"へ属する。

登録されているインスタンスインスタンス:"Instance1"と"Instance2"

※この二つのインスタンスがHTTPでELBから振り分けた通信を受け取る。

        "ELB1": {
            "Type": "AWS::ElasticLoadBalancing::LoadBalancer",
            "Properties": {
                "SecurityGroups": [
                    {
                        "Ref": "SecurityGroup2"
                    }
                ],
                "Instances": [
                    {
                        "Ref": "Instance1"
                    },
                    {
                        "Ref": "Instance2"
                    }
                ],
                "Listeners": [
                    {
                        "LoadBalancerPort": "80",
                        "InstancePort": "80",
                        "Protocol": "HTTP"
                    }
                ],
                "Subnets": [
                    {
                        "Ref": "Subnet2"
                    }
                ]
            },

 

ソース

www.dropbox.com

CloudFormationをいじる RDS編

RDSでのDB + WebAPの構成を作成する。

 

RDSを作成する際はパラメータが多いけど、

例のごとく最低限のパラメータで作成する。

 

以下のサイトが分かりやすい。

qiita.com

 

recipe.kc-cloud.jp

 

DBセキュリティグループとVPCセキュリティグループの違い。

今はDBセキュリティグループは使わないんだね。

docs.aws.amazon.com

 

 

テンプレ例 

最低限のパラメータで作るテンプレ例。 

DBサブネットグループテンプレ

サブネット:"Subnet2"とサブネット:"Subnet3"を持つDBサブネットグループ:"RDSSubnetGroup1"を作成

※RDSインスタンスが所属するDBサブネットグループは少なくとも2つのサブネットを持つ必要があるので、DBサブネットグループというものが存在する。2つのサブネットはAZが異なる必要があり、マルチAZのため?

        "RDSSubnetGroup1": {
            "Type": "AWS::RDS::DBSubnetGroup",
            "Properties": {
                "DBSubnetGroupDescription": "Subnet2 for RDS",
                "SubnetIds": [
                    {
                        "Ref": "Subnet2"
                    },
                    {
                        "Ref": "Subnet3"
                    }
                ]
            },
        },

 

サブネットテンプレ

VPC:"VPC1"に所属し、AZ:"us-east-1a"を持つ192.168.2.0/24のサブネット:"Subnet2"を作成

VPC:"VPC1"に所属し、AZ:"us-east-1b"を持つ192.168.3.0/24のサブネット:"Subnet3"を作成

異なるAZを二つ作成するためにAZを明示

 

        "Subnet2": {
            "Type": "AWS::EC2::Subnet",
            "Properties": {
                "AvailabilityZone": "us-east-1a",
                "VpcId": {
                    "Ref": "VPC1"
                },
                "CidrBlock": "192.168.2.0/24"
            },
        },

 

        "Subnet3": {
            "Type": "AWS::EC2::Subnet",
            "Properties": {
                "AvailabilityZone": "us-east-1b",
                "VpcId": {
                    "Ref": "VPC1"
                },
                "CidrBlock": "192.168.3.0/24"
            },
        },

 

セキュリティグループテンプレ

VPC:"VPC1"に紐づくセキュリティグループ:"SecurityGroup2"を作成。

送信元192.168.1.0/24からのインバウンド方向TCP/22~22 通信を許可。

 

        "SecurityGroup2": {
            "Type": "AWS::EC2::SecurityGroup",
            "Properties": {
                "VpcId": {
                    "Ref": "VPC1"
                },
                "GroupDescription": "Allow access only EC2",
                "SecurityGroupIngress": [
                    {
                        "CidrIp": "192.168.1.0/24",
                        "IpProtocol": "TCP",
                        "FromPort": "22",
                        "ToPort": "22"
                    }
                ]
            },
        },

 

RDSインスタンステンプレ

本体。

ストレージサイズ5GB、インスタンスタイプdb.m1.small、データベース種類MySQLのRDSインスタンスを作成

セキュリティグループ:"SecurityGroup2"、DBサブネットグループ:"RDSSubnetGroup1"、に所属させる。

ユーザー:"MyName"、パスワード:"MyPassword"で作成。

 

        "RDSInstance1": {
            "Type": "AWS::RDS::DBInstance",
            "Properties": {
                "AllocatedStorage": "5",
                "DBInstanceClass": "db.m1.small",
                "Engine": "MySQL",
                "MasterUsername": "MyName",
                "MasterUserPassword": "MyPassword",
                "DBSubnetGroupName": {
                    "Ref": "RDSSubnetGroup1"
                },
                "VPCSecurityGroups": [
                    {
                        "Ref": "SecurityGroup2"
                    }
                ]
            },
        },

 

上記テンプレを合体

VPC前回の記事を流用。RDS部分のみのコンポーネントは以下になる。

f:id:no1497:20170409215805p:plain

 

 

前回の記事と今回の記事を合体させたtemplateファイル。

 

www.dropbox.com

CloudFormationをいじる VPC EC2基礎編

AWS

CloudFormationをいじります。

最低限の操作を抑えたい。

 

となると、以下のサイトがとてもわかり易い。

dev.classmethod.jp

 

dev.classmethod.jp

 

 

テンプレ例

入門者向け、コピペで役立つ最低限のテンプレ。

VPCテンプレ

 

192.168.0.0/16のセグメントを持つVPC:"VPC1"を作成

        "VPC1": {
            "Type": "AWS::EC2::VPC",
            "Properties": {
                "CidrBlock": "192.168.0.0/16"
            },
        },

 

サブネットテンプレ 

VPC:"VPC1"に紐づく192.168.1.0/24のセグメントを持つサブネット:"Subnet1"を作成

        "Subnet1": {
            "Type": "AWS::EC2::Subnet",
            "Properties": {
                "VpcId": {
                    "Ref": "VPC1"
                },
                "CidrBlock": "192.168.1.0/24"
            },
        },

 

ルートテーブルテンプレ

VPC:"VPC1"と紐づくルートテーブル:"RouteTable1"を作成

※サブネットとの紐付けはプロパティに書かないんだ・・・。

以下、ルートテーブルサブネット結合必須

        "RouteTable1": {
            "Type": "AWS::EC2::RouteTable",
            "Properties": {
                "VpcId": {"Ref":"VPC1"}
            },
        },

ルートテーブルサブネット結合テンプレ

ルートテーブル:"RouteTable1"とサブネット:"Subnet1"を紐付けるルートテーブルサブネット結合:"RouteTable12Subnet1"を作成する。

        "RouteTable12Subnet1": {
            "Type": "AWS::EC2::SubnetRouteTableAssociation",
            "Properties": {
                "RouteTableId": {
                    "Ref": "RouteTable1"
                },
                "SubnetId": {
                    "Ref": "Subnet1"
                }
            },
        },

 

ルートテンプレ

ルートテーブル:"RouteTable1"に紐づく、宛先0.0.0.0/0のネクストホップを"IGW1"とするルート:"Route1"を作成

※ちなみにここでのIGW1はインターネットゲートウェイコンポーネント

        "Route1": {
            "Type": "AWS::EC2::Route",
            "Properties": {
                "DestinationCidrBlock": "0.0.0.0/0",
                "GatewayId": {
                    "Ref": "IGW1"
                },
                "RouteTableId": {
                    "Ref": "RouteTable1"
                }
            },
        },

セキュリティグループテンプレ

VPC:"VPC1"に紐づくセキュリティグループ:"SecurityGroup1"を作成。

インバウンド方向TCP/22~22 any通信を許可。

 

        "SecurityGroup1": {
            "Type": "AWS::EC2::SecurityGroup",
            "Properties": {
                "GroupDescription": "Allow SSH",
                "SecurityGroupIngress": [
                    {
                        "IpProtocol": "TCP",
                        "FromPort": "22",
                        "ToPort": "22",
                        "CidrIp": "0.0.0.0/0"
                    }
                ],
                "VpcId": {
                    "Ref": "VPC1"
                }
            },
        },

EC2作成テンプレ

セキュリティグループ:"SecurityGroup1"、サブネット:"Subnet1"に属するt2.microのAmazon Linux AMIインスタンス(バージニア北部 "ami-22ce4934")を作成

        "Instance1": {
            "Type": "AWS::EC2::Instance",
            "Properties": {
                "InstanceType": "t2.micro",
                "ImageId": "ami-22ce4934",
                "SecurityGroupIds": [
                    {
                        "Ref": "SecurityGroup1"
                    }
                ],
                "SubnetId": {
                    "Ref": "Subnet1"
                }
            },
        },

上記テンプレを合体

以下のようになります。

 

f:id:no1497:20170408212155j:plain

 

www.dropbox.com


AWS個人的に気になったワードまとめ(編集中)

  • Mシリーズインスタンス
    汎用利用のインスタンス種類。Tシリーズとは課金が異なる。
  • RI
    リザーブインスタンス。時間単価契約ではなく年間契約となる代わりに安く利用できる。
    【昔】
    軽度利用、中度利用、重度利用からの選択。
    【今】
    前払い、一部前払い、前払いなしから選択。
  • Cシリーズインスタンス
    コンピュート最適化のインスタンス
  • Route53のラウンドロビン
    DNSラウンドロビンが可能。Weightedなどポリシーオプションも豊富。
  • レイテンシーベースルーティング(Route53)
    アクセス元のレイテンシーを判断し、最も近いリージョンのアドレスを返すDNS機能。CDNは静的コンテンツだが、これであれば動的コンテンツも可能。
  • EBS BackedとS3 instance-store backed
    EBSはネットワークストレージ、instance-storeはホストの内蔵ディスクの一時間借りのようなもの。EBSはイメージとしてスナップショットが取れる、instance-storeはS3へ構成情報と一緒に取れる。EBSは有料、instance-storeは無料。EBSは不揮発性、instance-storeは揮発性※停止で消える、再起動では消えない
  • EBS backed AMIとinstance-store backed AMI
    EBSはEBSスナップショットとして保存。instance-storeはS3に保存。
  • S3マルチパートアップロード
    オブジェクトを分割して小分けにしてアップロードできるので途中で失敗しても大丈夫。並列アップロードが可能。
  • DynamoDB

NoSQL、KVSで構造がシンプルで応答が早いが検索と集計に弱い。容量を気にしなくてもよい。

本来、リージョンごとにしかログを取得できなかったがオプションとして選択するとこで利用リージョンのログをまとめて取得できるようになった。

オブジェクト単位のアクセス制御

  • S3バケットポリシー

バケット単位のアクセス制御

  •  MFA Delete

削除を行う際に、多要素認証を必須とする。(ワンタイムパスワードなど)

  • VMインポート

OVA形式のAWSへの読み込み。

Security Token Serviceの略。一時的、短期的な認証を許可するトークンを発行する。アプリの中で認証を払い出したりすることが多い。

大容量の連続データをストリーミング受信するためのフルマネージドサービス。SQSはユーザー操作が簡単。Kinesisは大容量。

  • クロスアカウント

異なるAWSアカウントのリソースの管理や操作が可能になるための機能。

 

 

 

Oracleのライセンス数を抑える方法

前回、Oracleライセンスについて簡単にまとめた。

今回はOracleライセンスを最も抑える方法を調べてみた。

前提としては仮想インスタンス単位ごとにOracle DBを扱うことを前提としました。

ゾーン集約など、ひとつのOSにDBを集約したりは考慮しません。

 

いきなり結論

Oracleライセンスを最も抑えることができるのは、

 

ハイパーバイザーにOracle VMを選択し、オンプレミスで構築すること

 

でした。

Oracle VMOracleがリリースしているxenベースのハイパーバイザーです。

他のハイパーバイザーとはライセンスのカウント方法が違う。

 

Oracle VM以外のハイパーバイザーの場合 


f:id:no1497:20170321232249j:image

 例としてvSphereを利用している場合、OracleDBが稼働しうるサーバの物理プロセッサーを見る。

 

SE2の場合・・・Active 2ソケット+Standby 2ソケット =合計4プロセッサーライセンス

EEの場合・・・Active 16コア×0.5(係数) + Standby 16コア×0.5(係数) = 合計16プロセッサーライセンス

 

EE高すぎるので、ちょっと現実的ではない。

 

Oracle VMがハイパーバイザーの場合

f:id:no1497:20170321232522j:image

同様にOracle DBが稼働しうるサーバの物理プロセッサーを見るが、待機系はカウントしない

 

SE2の場合・・・Active 2ソケット=合計2プロセッサーライセンス

EEの場合・・・Active16コア ×0.5(係数) = 8プロセッサーライセンス

 

仮にOracle DBが通常時動いている物理サーバが一台増えて合計3台になった場合は、増えた一台はActiveとしてそのサーバのプロセッサー分もライセンスが必要。

 

 

AzureやAWSと比較した場合(EEの場合)

 

話を簡単にするために2vCPU(コア)のOracle DBインスタンスを順次増やした場合の比較表は以下のような感じになる。

 コア係数を0.5とし、物理サーバは一台あたり16コア搭載(オーバヘッド除外してます)。待機系を一台常備。物理サーバの全てのコアリソースを使い果たしたら物理サーバを一台追加してそれにかかるOracle EEライセンスを追加購入した場合。


f:id:no1497:20170321234149j:image

16ごとにライセンス数はおいつきますが、基本的にAzure AWSよりはライセンス数を抑えられる。