Microsoft Tech Summit 2017 参加レポート #mstsjp17

初めまして。SIOS Coati 開発チームでProduct Ownerの任に就いている大野と申します。

普段本Blogでは、Coatiの開発エンジニアが記事を作成しておりますが、投稿は開発者に限定するというルールがあるわけでもありません。今回は私が、MicrosoftさんのTech Summit 2017 #mstsjp17@東京ウェスティンホテルに参加してきましたので、CoatiのPOの視点から、興味を引いたセッション等についてレポートしたいと思います。

※写真を撮らせていただいたものもありますが、色々な方が写っているので本記事は文字のみです。ご了承ください。

基調講演

なにはともあれ、基調講演です。「変化のとき、進化のとき ITイノベーションがもたらす価値」というタイトルでした。複数の方がご登壇されて、色々な革新的技術についてのサマリを紹介されておりました。ざっと(記憶にあるものを)挙げるとこんな感じです。

  • Microsoft 365 (M365というみたいですね)
    • Office 365 + Windows10 + Enterprise Mobility + Security
    • ホワイトボード共有とかできる
    • PowerPointのデザインとか提案してくれる
  • Azure Stack
    • 今回個人的に一番興味深かったです
    • Azureと(ほぼ)同じ機能を持ったアプライアンスサーバ
    • Public Azureと、オンプレ的に配置するAzure Stackの連携
  • SQL Server 2017
    • Windows & Linux & Docker
  • Cosmos DB + Azure Functions
    • ナビタイムがデモをやられておりました
      • Chatbot、文字や画像解析など
  • Mixed Reality
    • Hololensというヘッドマウント・ディスプレイの中で、多人数で共有できるVR(と言ってしまって良いのかな?)を実現
    • デモとして、橋を作っている工事現場と実際に繋いで、どういう形で橋がかかるのか、重機の類がどのように配置されるのかなどを視覚的に共有
    • 体験ブースもあり。私はセッションまわるのに忙しくて試せませんでしたが
  • AI
    • Chatbotや「りんな」の発展でキャラクター化
    • 自動翻訳、実際にいくつかのセッションでは、スピーカーの話(日本語)がリアルタイムに英語字幕なっていました
    • Cortana & Alexaで協力
    • Azure Machine Learning Workbench
      • 機械学習に取り込むデータ分類、整理を行うツール
  • Quantum Computing
    • 正直難しい(笑)
    • 量子コンピュータ用の言語をF#ベースで作成(名称未定)
    • Visual Studioで開発可能

特に興味深かったのは、Azure StackとMixed Reality(MR)です。Azure Stackは、SIOS Coatiを始めいくつかの製品において絡んでいけるかも知れません。MRについては、業務上の関連はほぼ無さそうですが、ユーザー視点では非常に面白そうです。大変デモ映えがします。あれはもうSFの世界ですね。

その他のセッションの感想

ひとつひとつのセッションについて感想を書いていくと、記事が膨大な長さになりそうです。今回私は、Azure Stack、コンテナ、インフラエンジニア向けセッションという内容を中心に回ってきました。それらについて包括的にレポートしたいと思います。

Azure Stack

これは、面白いですね。日本企業向けという感じがしました(完全にイメージだけの話ですけれど)。これが一体なにかと言うと、端的にはソフト+ハード+サポートのアプライアンス製品だとのことです。ソフトウェア部分に、マイクロソフトさんが提供するパブリッククラウドのAzureとほぼ同じ機能を備えたAzureが入っています。PaaSもマーケットプレイスも使えます。これを搭載するハードウェアは固定というか、Azureインストール済みのハードとして販売されます。適当なハードにインストールして使うようなことはできません。当然サポートもあります。

ユースケースとしては、「何らかの理由でパブリッククラウド上に置くことができないデータやアプリをオンプレミス環境的に取り扱いたい」、でも「クラウドの利便性も欲しい」というユーザーに最適とのことです。なるほどー、と思いましたね。日本企業のユーザーさんは、まだまだこういった会社も多いのではないでしょうか。

クラウドベンダーがどれだけのセキュリティ認証を取得していようと、またユーザーが自前でセキュリティを固めるよりもクラウドの方が遥かに強固だと解ってはいても、「このデータ外に出すべからず」の一文がどうしても破れない、という組織はまだまだ多いように思われます。そういった組織でもクラウドを導入しやすくなるでしょうね。

このAzure Stack (オンプレ) + Public Azure の構成を指して「Hybrid Cloud」と呼んでおられました。なんかこれはしっくりきますね。全然異なるアーキテクチャのものを混ぜている訳でもなく、ロケーションとしてはオンプレとクラウドで分離されている。結構いいとこ取りな構成なのではないでしょうか。

コンテナ

恥ずかしながら、私コンテナについてもあまり知識がなかったもので、今回は大変勉強になりました。いくつかのセッションでお伺いしたお話は、おそらくAzureだから特別にこうだ!というところはほぼ無かったようです。やはり、DockerにしてもWindowsは後発であり、先行するLinux上のDockerと比べて、ほぼ遜色無く使えます、という話が良く聞かれました。

Coatiは現状AWS上のAMI上で動作しており、1Coatiインスタンスは1AMIを専有しています。今後、可搬性などを考えると、Coatiをコンテナ上で動かせるようにして様々な環境で動作できるようにするというのもひとつの手かも知れませんね。(大変なのかな。大変なんだろうな(笑))

インフラ関連

インフラ関連と書いてしまうとあまりにざっくりですが、まあ「その他インフラ周りで気になったもの」と捉えていただければと思います。

ひとつ興味深かったのは、Azure上のDRとBCPの解説です。Azure上の災対サイト構築はこんなに簡単でお安くできますよという趣旨のセッションなのですが、その中で紹介されていたAzure Site Recovery (ASR)という機能がなかなか素敵です。Azure to Azure はもちろん、オンプレ to Azureにも対応するDataReplicationをサービスとして提供するもので、フェイルオーバー・フェイルバックが簡単に行えます。現在はPublic Previewとのことで、次の年末~年始くらいにはサービス開始のアナウンスがあるかも知れません。

また、「モダンなインフラ」をテーマにしたセッションでは、様々なトピックについてお話を伺いましたがその中で興味を引いた情報として、GUIが切り離されたWnidows Serverがリリースされるというものがありました。びっくりです。

ちょっとググったら情報ありました。もう入手可能みたいですね。
http://www.atmarkit.co.jp/ait/articles/1711/07/news012.html

また、個人的に本当に素晴らしいなと思ったのは、Microsoftのテクノロジーセンター長の澤さんのセッション「IT用語で語る!なぜIT屋の話は伝わらないのか~エンジニアのためのコミュニケーションスキルアップ~」です。著名な方なので、お名前は聞いたことはあったのですが、実際にプレゼンを聞いたのは今回が初めてでした。…凄いですね、プロっているんですね。感心を通り越して感動しました。ITエンジニアが非エンジニアとコミュニケーションを取る際に、注意するべきことについてまとめられた内容なのですが、その説明が極めて秀逸、会場中が笑いの渦でした。こんなセッションもあるのですね。

普段なかなか、Microsoftさんの製品、サービスについて勉強をする機会がありませんでしたので、今回の参加は非常に刺激になりました。あと、お弁当美味しかったです。ごちそうさまでした。

Windows Server 2016に対応しました

SIOS Coati開発チームの清水です。

先日のアップデートで、SIOS Coatiで監視できるOSとして Windows Server 2016 に対応しました!

すでにSIOS Coatiをご利用の方は、特別な対応をしていただく必要はございません。
これまでと同様にセットアップしていただくことで、すぐに監視をはじめることができます。

まだSIOS Coatiを使ったことのないお客様で、Windows Server 2016をご利用の方は、是非この機会に無料トライアルでお試しください。

無料トライアルは こちらの製品ページ から申し込むことができます!

ansibleによるEC2・VPC環境構築(その3)

食欲の秋に(体重的な意味で)危機感を覚える Coati開発チーム 沼野井です。
でも秋の味覚を食べないという選択肢はないですよね!

 

前回までのあらすじ

ansibleで、

 

VPCと、それに紐づく サブネットルートテーブルセキュリティグループを作ったCoatiだった・・・

 

というわけで、前回に続いて、ansibleでEC2・VPC環境を構築していこうと思います。

今回は、

  • 前回作成したSIOS VPC内に EC2インスタンスを作成
  • 前回作成したSIOS VPCとお客様VPCをPeeringで接続

します。

 

Playbookの内容

Coatiチームで使用している、環境デプロイ用のPlaybookのディレクトリ構成と、変数定義をしているall.ymlの内容をもう一回掲載します。

  • ディレクトリ構成

├── ansible.cfg
├── group_vars
│   └── all.yml                       # 変数定義
├── hosts
├── roles
│   ├── VPC
│   │   └── tasks
│   │       ├── main.yml              # VPC.ymlの本体
│   │       ├── setup_ec2.yml         # VPC.ymlの本体
│   │       └── setup_vpc.yml         # VPC.ymlの本体
│   └── vpc_peering
│       └── tasks
│           ├── main.yml              # VPC.ymlの本体
│           └── vpc_peering.yml       # create_vpc_peering.ymlの本体
├── create_vpc_peering.yml            # 実行するplaybook
└── VPC.yml                           # 実行するplaybook

 

group_vars/all.yml

 


PEERING_VPC_ID: vpc-XXXXXXXX                     # お客様のVPC ID
PEERING_VPC_CIDR: XXX.XXX.XXX.XXX/XX             # お客様のVPC CIDR
CUSTOMER: Coati Coffee.break.fun                 # お客様名
EMAIL: COATI@coati.coffee_break_fun.com          # お客様のEメールアドレス

PREFIX: "CoatiManager_{{ CUSTOMER }}"            # VPC, Subnet, ルートテーブル, インスタンス名のprefix
REGION: ap-northeast-1                           # リージョン(東京)
OFFICE_IP: ZZZ.ZZZ.ZZZ.ZZZ                       # SIOSのオペレーション端末のIPアドレス
OFFICE_IP_CIDR: "{{ OFFICE_IP }}/32"             # SIOSのオペレーション端末のIPアドレスのCIDR
VPC_NAME: "{{ PREFIX }}_VPC"                     # VPC名称
VPC_CIDR_LEFT: YYY.YYY.YYY                       # Coati ManagerのCIDRの左部分
VPC_CIDR_BLOCK: "{{ VPC_CIDR_LEFT }}.0/23"       # VPCのCIDR Block
SUBNET1_NAME: "{{ PREFIX }}_SUBNET1"             # Subnet名
SUBNET1_CIDR_BLOCK: "{{ VPC_CIDR_LEFT }}.0/24"   # SubnetのCIDR Block
ROUTETABLE1_NAME: "{{ PREFIX }}_RT1"             # ルートテーブル名

KEY_PAIR: XXXXXXXXXXXXXXXXXXXXXXXXXXX      # Coati Managerインスタンスにアクセスするためのキーペア
INSTANCE_TYPE: t2.small                # Coati Managerインスタンスのインスタンス・タイプ
EC2_NAME: "{{ PREFIX }}"                         # Coati Managerインスタンス名
EC2_PRIVATE_IP: "{{ VPC_CIDR_LEFT }}.10"         # Coati ManagerインスタンスのプライベートIPアドレス
IAM_ROLE: XXXXXXXXXXXX                           # Coati Managerインスタンスに割り当てるIAMロール
SIOS_ACCOUNT_ID: 987654321098                    # サイオスのAWSアカウントID

 

インスタンス作成

作成したVPC内にEC2インスタンスを作成するplaybook, setup_ec2.ymlの中身を見ていきます。


- ec2_remote_facts:
    region: "{{ REGION }}"
    filters:
      private-ip-address: "{{ EC2_PRIVATE_IP }}"
      subnet-id: "{{ SUBNET_ID }}"
  register: ec2

# Search for the AMI tagged "Role: CoatiManager" and "Version: Master"
- ec2_ami_find:
    owner: self
    region: "{{ REGION }}"
    ami_tags:
      Role: CoatiManager
      Version: Master
    sort: creationDate
    sort_order: descending
    sort_end: 1
    no_result_action: fail
  register: ami_find

- name: Create AWS Instance
  ec2:
    key_name: "{{ KEY_PAIR }}"
    instance_type: "{{ INSTANCE_TYPE }}"
    image: "{{ ami_find.results[0].ami_id }}"
    region: "{{ REGION }}"
    vpc_subnet_id: "{{ SUBNET_ID }}"
    private_ip: "{{ EC2_PRIVATE_IP }}"
    instance_profile_name: "{{ IAM_ROLE }}"
    assign_public_ip: no
    wait: yes
    instance_tags: 
      Name: "{{ EC2_NAME }}"
      Role: CoatiManager
    volumes:
      - device_name: /dev/sda1
        volume_type: gp2
        volume_size: 20
        delete_on_termination: true
  when: not ec2.instances

# refresh remote facts
- ec2_remote_facts:
 region: "{{ REGION }}"
 filters:
 private-ip-address: "{{ EC2_PRIVATE_IP }}"
 subnet-id: "{{ SUBNET_ID }}"
 register: ec2

- name: Associate EIP for instance
 ec2_eip:
 region: "{{ REGION }}"
 device_id: "{{ ec2.instances[0].id }}"
 reuse_existing_ip_allowed: yes
 in_vpc: yes
 register: eip

順にみていきます。


- ec2_remote_facts:
  region: "{{ REGION }}"
    filters:
      private-ip-address: "{{ EC2_PRIVATE_IP }}"
      subnet-id: "{{ SUBNET_ID }}"
  register: ec2

ec2_remote_factsはAWS内の(複数の)インスタンスの情報を集めるモジュールです。
IPアドレス・サブネット名など多種のFilterを設定して検索することができます。
今回は、SUBNET_IDのサブネット、EC2_PRIVATE_IPのIPアドレスのインスタンスが、環境内に既に存在しているかどうかをチェックしています。

なお、ec2_remote_facts は ansible 2.4 では非推奨モジュールとなっており、代わりに ec2_instance_facts がリリースされています。

- ec2_ami_find:
    owner: self
    region: "{{ REGION }}"
    ami_tags:
      Role: CoatiManager
      Version: Master
    sort: creationDate
    sort_order: descending
    sort_end: 1
    no_result_action: fail
  register: ami_find

続いて、AMIの検索です。
Coati開発チームでは、Coati Manager用のAMIをあらかじめ用意していて、タグ Role=CoatiManager をつけています。ec2_ami_findモジュールを利用して、タグをキーにしてAMIのIDを取得します。


- name: Create AWS Instance
  ec2:
    key_name: "{{ KEY_PAIR }}"
    instance_type: "{{ INSTANCE_TYPE }}"
    image: "{{ ami_find.results[0].ami_id }}"
    region: "{{ REGION }}"
    vpc_subnet_id: "{{ SUBNET_ID }}"
    private_ip: "{{ EC2_PRIVATE_IP }}"
    instance_profile_name: "{{ IAM_ROLE }}"
    assign_public_ip: no
    wait: yes
    instance_tags: 
      Name: "{{ EC2_NAME }}"
      Role: CoatiManager
    volumes:
      - device_name: /dev/sda1
        volume_type: gp2
        volume_size: 20
        delete_on_termination: true
  when: not ec2.instances

いよいよ、インスタンスの作成です。そのものズバリな ec2モジュールを使います。
パラメータはAWS Management ConsoleでEC2インスタンスを作成する際にお馴染みな面々を指定していきます。imageには、さきほど検索したAMIのIDを指定しています。

    image: "{{ ami_find.results[0].ami_id }}"

instance_tags: で Name=名前, Role=CoatiManager、というタグ付けもしています。

最後の

  when: not ec2.instances

は、ec2.instancesがある場合にはインスタンスの作成をしない、という条件判定です。
一番最初に ec2_remote_factモジュールで同じIPアドレスとサブネットのインスタンスを検索したときに、もし既に存在している場合には変数ec2.instancesなんらかの値が入っているはずですので、その場合にはインスタンスの作成は行わないようにしています。

 

VPCピアリング接続

VPCピアリングを行うplaybook, vpc_peering.ymlです。

---
- name: include vars
  include_vars: '/tmp/__temp_fact__.yml'

- name: Setup VPC peering for customer
  ec2_vpc_peer:
    region: "{{ REGION }}"
    vpc_id: "{{ manager_vpc_id }}"
    peer_vpc_id: "{{ PEERING_VPC_ID }}"
    peer_owner_id: "{{ PEER_OWNER_ID }}"
    state: present
    tags:
      Name: Peering connection for "{{ CUSTOMER }}"
  register: vpc_peering_for_customer

 

ec2_vpc_peerモジュールを使い、接続するVPCをそれぞれ指定して、VPCピアリング接続を行います。
このplaybookを実行したあと、お客様に接続を承認していただくと、晴れて両VPCがピアリング接続されることになります。

ここまでの結果

ついに、Coati環境が完成しました!

いかがでしたでしょうか?
今後も、役に立ちそうなplaybookを紹介していく予定ですので、よろしくお願いします。

 

名古屋に続き「AWS Cloud Roadshow 2017 福岡」にも出展します!

皆様、こんにちは、SIOS Coatiのマーケティング担当をしております吉岡です。

先日ご案内しましたAWS Cloud Roadshow 2017 名古屋はブースに数多くの方にお越しいただき、大盛況のもと終わりました!

さて、ちょっと告知が遅くなってしまいましたが、

2017年10月31日(火)に、アマゾン ウェブ サービス ジャパン株式会社主催の無料クラウドカンファレンスであるAWS Cloud Roadshow 2017 福岡に出展いたします。

このイベントもここで最後となりますが、多くの方にSIOS Coatiを知っていただければと思います。

展示ブースでは、Amazon EC2上で稼働するアプリケーションを自動復旧するクラウドサービスSIOS Coatiをご紹介します。ぜひ、お立ち寄りください。

概要

AWS Cloud Roadshow 2017 福岡

日時:2017年10月27日(水) 10:00~20:00(開場:9:30)
会場:ANA クラウンプラザホテル福岡 
(〒812-0011 福岡県福岡市博多区博多駅前3丁目3−3)

本イベントの詳細、お申込みはこちらのサイトをご覧ください。

シンプルなEC2インスタンスの自動起動・停止について

こんにちは、SIOS Coati開発チームの黒田です。

開発や検証などを目的とした環境では、不要なEC2インスタンスの停止や削除は、
システムのランニングコスト削減に対して小さくない効果があります。
特に前月からはEC2の課金単位が、時間単位から秒単位へ変更となっておりますので、
停止・削除によるコスト削減がより効果的なものとなっています。

このような停止・削除といった操作は、EC2インスタンスの数が少ないうちは手動で
行われても良いかも知れませんが、実は地味に面倒な作業でもあります。
うっかり止め忘れたために想定以上の費用がかかってしまうケースも…?

そこで今回は、AWS Lambdaのスケジュール機能を利用した、
シンプルなEC2インスタンスの自動起動・停止方法を紹介したいと思います。

基本動作としては、全てのリージョンで、以下の特定タグが設定されているEC2インスタンスを
スケジュールされた時間に自動起動・停止します。

EC2インスタンスタグの動作一覧

key value 動作
Ec2StartStop Auto 起動・停止を実行
Ec2StartStop Start 起動のみ実行
Ec2StartStop Stop 停止のみ実行

※タグのkeyやvalue名は、環境にあわせて設定してください。

設定するAWSサービス

  • Lambda
  • IAM Role
  • CloudWatch Event

設定方法

Lambda

1.AWS マネージドコンソールへログインしてからAWS Lamdbaサービスを選択し、関数の作成を選択します。


 

2.トリガーの設定をスキップし、次へを選択します。


 

3.Lamdba関数の「名前」を入力し、ランタイムは「Python3.6」を選択します。


 

4.コードをインラインで編集します。

コードのサンプルは、以下になります。

import boto3


def lambda_handler(event, context):
    awsRegions = boto3.client('ec2').describe_regions()['Regions']

    for region in awsRegions:
        awsregion = region['RegionName']
        ec2 = boto3.resource('ec2', region_name=awsregion)

        instances = ec2.instances.all()

        start_list = []
        stop_list = []
        action = event['Action']

        for i in instances:
            if i.tags != None:
                for t in i.tags:
                    if t['Key'] == 'Ec2StartStop':

                        if t['Value'] == 'Auto' or t['Value'] == action:
                            if action == 'Start' and i.state['Name'] == 'stopped':
                                    start_list.append(i.instance_id)
                            elif action == 'Stop' and i.state['Name'] == 'running':
                                    stop_list.append(i.instance_id)

        if start_list:
            print('Starting', len(start_list), 'instances', start_list)
            ec2.instances.filter(InstanceIds=start_list).start()

        elif stop_list:
            print('Stopping', len(stop_list), 'instances', stop_list)
            ec2.instances.filter(InstanceIds=stop_list).stop()

※必要に応じてコードを変更してください。

IAM Role

5.「Lambda 関数ハンドラおよびロール」の「ロール」で、「カスタムロールの作成」を選択します。


 

6.「ロール名」と「ポリシードキュメント」を入力してください。

ポリシードキュメントは、以下になります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:Start*",
        "ec2:Stop*"
      ],
      "Resource": "*"
    }
  ]
}

 

7.「詳細設定」の「タイムアウト」値の変更

デフォルト3秒から30秒へ
※タイムアウト値は、環境にあわせて変更してください。

CloudWatch Event

 

8.まずは、起動のスケジュール設定をします。AWS CloudWatchサービス画面に移動し、「イベント」->「ルール作成」を選択してください。


 

9.「イベントソース」のスケジュールを選択し、「Cron式」を選択して、起動時間のcron式を入力してください。

cron式(UTC)

30 23 ? * MON-FRI *

※環境にあわせて起動時間を変更してください。


 

10.「ターゲットの追加」を選択し、作成したLambda関数(Ec2StartStop)を選択します。「入力の設定」の「定数(JSONテキスト)」を選択し、以下を入力してください。

定数(JSONテキスト)

{"Action": "Start"}


 

11.「名前」を入力と「状態」の「有効」をチェックし、「ルールの作成」を選択します。


 

12.停止スケジュールの設定をします。以下のようにcron式と定数(JSONテキスト)を入れ替え、8~11の手順を繰り返してください。

cron式(UTC)

00 13 ? * MON-FRI *

※環境にあわせて停止時間を変更してください。

定数(JSONテキスト)

{"Action": "Stop"}

 

13.動作確認を行います。EC2インスタンスにタグを設定し、スケジュールされた時間にEC2インスタンスが起動・停止されているかを確認してください。

以上、AWS Lambdaのスケジュール機能を利用したシンプルなEC2インスタンスの自動起動・停止方法の紹介でした。