新年明けましておめでとうございます!

皆様、明けましておめでとうございます!

SIOS Coatiのマーケティング担当をしております吉岡です。

 

皆様は年末年始をいかがお過ごしされましたでしょうか?

 

今年もこちらのBlogではSIOS Coatiの機能、新サービスをはじめとし、

パブリッククラウドでの運用に関連する情報や技術情報を発信していきたいと思います。

 

また今年は昨年以上にイベントやセミナーの開催も行っていく予定ですので、

その辺の情報もこちらでお伝えしてまいります。

 

今年もクラウドはかわらず市場を大きくしていくと思いますので、

その中でSIOS Coatiが皆さんの運用を楽にしていくべく、様々な機能を追加し、ご提供していければと思います。

 

 

AWSの新機能「Inter-Region VPC Peering」でリージョン間VPCピアリングしてみた

国内・海外問わず旅行好きなSIOS Coati開発担当、沼野井です。

 

さて、先日のAWS re:invent 2017では例によってたくさんの新機能がお披露目されましたが、その中の1つ、

Inter-Region VPC Peering

で、リージョン間のVPCピアリングが可能になりました。

今のところ、できるリージョンは

  • 米国東部(バージニア北部)
  • 米国東部(オハイオ)
  • 米国西部(オレゴン)
  • 欧州(アイルランド)

の4つです。残念ながら東京は入ってないんですが、AWSのことなのできっとすぐにできるようになるでしょう。

というわけで、今回はこのInter-Region VPC Peeringを試してみました。

 

ピアリング接続を作成してみる

まず、バージニアとオハイオにVPCを作ります。

バージニア

 

 

オハイオ

 

で、バージニアの方からオハイオにピアリング接続を作成してみます。

バージニアの方で、ピアリング接続の作成画面を開きます。

リージョンを選択するカラムが追加されていますね。オハイオを選んで作成!

成功! 

あとは、同一リージョン内のVPCピアリングと同じようにオハイオ側が承諾すれば完了です。

 

 

無事できました。すごいですね。

 

通信してみる

せっかくなんでインスタンス作って通信してみました。

バージニア

 

オハイオ

 

ping飛ばしてみました。

東京リージョン内の2つのVPCピアリングで接続した2つのインスタンスでのping結果を速度比較してみます。

 

おっ意外と差がありますね? 

まあ、条件などを考慮した厳密な測定では全くないのでご参考、ではありますが、シビアに速度を気にするアプリを開発されている方は、計測・検証が必要かもしれません。

 

CLIで作成してみる

さて、GUI(Management Console)では無事作成できたリージョン間ピアリングですが、CLIではできるんでしょうか?

先ほど作成したVPC Peeringをいったん消して、CLIで再度作成してみましょう。

VPCピアリングを作成するコマンドは aws ec2 create-vpc-peering-connection–peer-region ですが、–peering-regionオプションでピアリング先(アクセプタ)のリージョンを指定すればよいようです。

バージニアに作成したインスタンスでCLIを実行してみます。

DEKITA! CLIもばっちりです。

 

Ansibleでできるか調べてみる

ansibleはどうかな? と思って調べましたが、さすがにまだ未対応のようです。

ec2_vpc_peerモジュール

ピアリング先(アクセプタ)のリージョンを指定することができません(注:上記ページ内のExampleのregionは、ピアリング元(リクエスタ)のリージョンの指定です)。

あせらず、でも期待して待ちましょう!

 


リージョン間ピアリングは使い所が多そうです。SIOS Coati世界展開も近いかも知れません(!?)

この調子でリージョン間ピアリングを通して物理的に人間の輸送ができるようになったりしませんかね? 海外旅行が捗るんですが。
ジェフ・ベゾスさんならあと20年くらいでやってくれそうな気もします。

12/8、AWS/ソニー/サイオス共催セミナー報告

皆様、こんにちは、SIOS Coatiのマーケティング担当をしております吉岡です。
12月8日(金)にAmazon Web Services Japan、ソニーネットワークコミュニケーションズ様と共催でのセミナーを開催いたしました。
当日はどんな話をしたのかと言いますと

オンプレミス環境からAWSへの移行の勘所
~プラン策定から移行、稼働までの概観をご紹介~

と題してAWS Japan様からオンプレからAWSに移行する時の手法、ツールについての紹介がありました。

最近はAWS関連のセミナーも基本的な移行方法であったり、移行するにあたって考えるべきことなどは減ってきていますが、ここでは本当に基本的なプランの策定をどうすべきか、移行時に注意すべき点はどこかなどを丁寧に紹介されていました。

こちらは開始前の会場。最終的には満席に。

 

そして次にソニーネットワークコミュニケーションズ様からは

移行して終わり!ではない…運用管理性を高める独自開発ツール“クラウドポータル”活用術

と題して、ソニー様が提供する独自開発のツール「クラウドポータル」のご紹介です。こちらのツールはAWSをはじめての方でも直感的に使える、既に利用されている方はもっと効率よく使えるよう、運用支援ツールです。
サービスの詳細はこちらをご確認ください。
なぜソニーネットワークコミュニケーションズと一緒にセミナーかと言いますと、このクラウドポータルとSIOS Coatiは連携しているのです。
クラウドポータルはAWSの利用状況を簡単に可視化できるサービスなのですが、こちらでSIOS Coatiの利用時間などを見ることができるのです。
なのでクラウドポータルとSIOS Coatiを一緒に使いたいなという方はソニーネットワークコミュニケーションズ様にご相談するとワンストップでサービスを利用することができます。
そして最後に私の方から

移行して終わり!ではない…不安から解放!ローコストな監視&自動復旧サービスとは

と題してSIOS Coatiの紹介をさせていただきました。
名古屋ではこれからAWSを利用という方が多いようで、みなさん移行後の運用について関心が強く、
多くの皆様が関心を持っていただけたみたいでした。
こちらのセミナーは来年また東京、大阪で開催を予定しております。
詳細決まりましたら、またご案内をさせていただきます。

ファイル構成をYAMLでコード化する

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

突然ですが、みなさんはファイル構成のコード化をどのようにおこなっていますか?

SIOS Coatiでは、環境の構築をAnsibleで行っています。Ansibleは非常に便利(どのくらい便利かは別の記事に譲ります)ですが、ちょっとしたひな形としてディレクトリやファイルを作るのには、少し大袈裟になりがちです。

たとえば個人的に、Pythonで開発をはじめるときは下のような構成が欲しかったりします。

このようにYAMLだとディレクトリの関係が綺麗に表現できます。

ならばいっそ、このYAMLからディレクトリ・ファイルをファイル構成を自動展開するスクリプトがあったらいいなと思ったので、作成しました。

普段からよく使う構成をYAMLにしておけば、ディレクトリ構成をドキュメント化しておく必要もありませんし、チーム内でひな形をお手軽に共有することもできます。

 

スクリプトと使い方を本記事の末尾に記載しますので、興味があるかたはぜひお試しください(スクリプトのご利用はあくまで自己責任でお願いいたします)。

なお実行にはPython3とPyYAMLライブラリが必要となるため、あらかじめインストールしてください。


ソースコード

template.py を作成し、以下のコードをコピー&ペーストしてください。

コマンドのフォーマット

サンプルコマンド

config.ymlの構成に基づいて、新しいファイル・ディレクトリを ./out ディレクトリ上に展開します。

なお、-o オプションを省略した場合は、カレントディレクトリ上に展開します。

もし、既にファイルが存在している場合は、その時点でプログラムは停止します(既存のファイルを変更することはありません)。

作成前にファイルの存在確認をする(Dry Run)場合は -d オプションを付与してください。


シンプルなコマンドですが、使いどころはあると思います。ぜひ使ってみてください!

re:Invent 2017に行ってきました

皆様、こんにちは、SIOS Coatiのマーケティング担当をしております吉岡です。
今年も昨年に続き、Amazon Web Serviceが主宰するイベントre:Invent 2017に行ってきました。
こちらのイベントはご存知の方も多いと思いますが、年々規模が拡大していき、
昨年は約30,000人で、今年は43,000人でライブストリーミングには60,000人が参加となりました。
こちらはメイン会場へのゲートです。
イベントそのものの内容ですとかはAWS Japanをはじめ、様々な方々紹介しているので、ここではISVの視点でお話をしたいと思います。
re:Inventではセッションだけではなく、ISVによる展示会場があり、多くのISVが出展しています。
企業によってはここで1年分の商談を稼ぎ出すぐらいの会社もあるくらいです。
こちらはExpo会場の様子です。
日本と違って、AWSのイベントブースに来る来場者(AWSユーザ)はかなり本気で3rd Party製品の情報を収集しており、展示ブースの方々の真剣度も高いです。
昨年出展していたところも多くありますが、新たに大きなブースで出展している企業もあり、ベンチャーでありながら大きな投資をしてこのイベントでのリード取得にかけていることが伝わってきました。
AWSは毎年このイベントで多くの新しいサービスを発表してきますが、ISVからするとヒヤヒヤするところもあります。
AWSが同じような機能をいきなり実装された場合、ISVとしてはいきなりThe Endがくると感じました。
この辺はISVの宿命ではありますが、クラウドの進化するスピードを見極めつつ、Value Propositionを常に考えてより良いサービスをどう提供していくか、どう見せていくかを考えてなければならないと痛感した良い経験となりました。
来年(来年を待たずに色々と出ると思いますが、)はどんなサービスが出てくるのか楽しみです。