AWS Blog

DATE2017.05.14

AWS基盤上でCitrix社XenAppの利用


VDI/SBCの製品においてリーダーであるCitrix社のXenDesktop/XenAppはAWS上でも利用する事ができます。 AWS上ではアプリケーション配信のXenAppとして利用するのが一般的だと思いますが、 今回はCitrixが提供するサーバVDI方式とAWSを組み合わせた構成についてご紹介したいと思います。

以下、Citrix XenApp及びAWSのアーキテクチャになります。

20170514_Citrix02.png

サーバVDIは名前の通り、Windows Server OSでデスクトップ配信を行います。 恐らくAmazon WorkSpacesも同じ様な仕組みで実装されていると考えています。 一般的にはマスターイメージを用意して各サーバの展開に利用しますが、AWS上ではマスターイメージはAWSのAMI(amazon machine image)を使用します。

XenAppコントローラでAMIを指定して各サーバVDIを展開していくことができます。
この動作から分かる方も多いのではないかと思いますが、XenAppコントローラにIAMのアクセスキーを登録し、 AWSのAPIエンドポイントを介して連携を行います。
オンプレミス環境と同様にXenAppはActive Directoryへのコンピュータのドメイン参加も行ってくれるため、 サーバVDIの展開を全て自動で行うことができます。


20170514_Citrix01.png CitrixにはAWS基盤の電源管理機能も備えており、パブリッククラウドの有効活用の特徴である必要な時だけリソースを利用することもできます。
例えば、勤務開始の9時と同時にEC2を起動し、勤務が終わる18時に停止をすることも可能です。 これにより日々のEC2の料金を9時間分となり大幅なコスト削減につながります。 ログオン時のみEC2を起動させる機能も用意されており、毎週1日勤務をするパートナーに正社員と同様のセキュアなPC環境を低コストで実現することもできます。

これらの機能はCitrix XenApp 7系のLTSRである7.6で扱うことができます。 詳細は公式のドキュメントをご確認ください。

AWS上でのVDI/SBCを利用する場合は、AWSが提供するAmazon WorkSpacesやAmazon AppStream 2.0もあります。 Citrix XenAppとAmazon WorkSpaces/AppStream 2.0のどちらを利用する方が良いかどうかは要件ごとに検討する必要があると思いますが、 長年エンタープライズ向けに製品を提供をしているCitrix XenAppを選択する理由は多くあると考えています。

青沼

DATE2017.05.11

AWS基盤上で Palo Alto Networks社 VM-Series の利用


重要なシステムをパブリッククラウドで利用している人も増えてきているのではないかと思います。 ファイアウォール製品でリーダーのPalo Alto Networks社の仮想アプライアンス版であるVM Seriesの構成例についてご紹介します。

pa-vm_20170511.png

細かな制御をしない場合はAWS内のネットワークを意識しないことが多いですが、VM Seriesを使用する場合は、 構成図のようにENI(Elastic Network Interface)とルーティングを整理する必要があります。

AWSのセキュリティグループや送信元/宛先チェックといった設定はENIの設定のため、アタッチするENIごとに意識する必要があるのでご注意ください。 セキュリティグループのエントリ数には上限があるため、使い分けを行いネットワークセキュリティを強化することができます。 また、グローバルIPアドレスを使用する場合はEIPを使用するため、VM Seriesの設定と合せて関連付けて設定を行う必要があります。

VM SeriesのActive/Standby構成は、Active側のみサービス通信用のENIを持ち、 フェイルオーバ時はVM SeriesがAWSのAPIを実行してENIの付け替えを行う形で切り替わります。

環境や障害内容によって切り替わり時間が変わる可能性がありますが、当社検証環境ではActive機の障害時に30秒以内で切り替わりが行われている事を確認しています。

今回、AWS基盤とVM Seriesの繋ぎ目部分を中心に書かせていただきましたが、VM Seriesを使用することでセキュリティを大幅に高めることができます。 ハードウェアアプライアンス版と同じく既知のマルウェアから保護するアンチウィルス機能、未知のマルウェアから保護するWildFire機能、URLフィルタリングや通信の可視化で入口対策や出口対策が可能です。

当社、AWS上のVM Series構築サービスの詳細は以下になります。
https://www.crosshead.co.jp/AWS/aws-pa.html


青沼

DATE2017.04.11

EC2のAuto Recovery機能は本当に動作するのか?(→しました)

クラウドチームのかたやまです。久しぶりの投稿です。

今日は、EC2のAuto Recovery(自動復旧)機能について書いていきます。Auto Recoveryというのは、EC2の動作環境でハードウェア障害などが発生した場合、その障害をトリガとしてインスタンスを自動的に復旧してくれる機能のことです。

AWSの説明によると、以下の状態がAuto Recoveryの対象になるようです。

  • ネットワーク接続の喪失
  • システム電源の喪失
  • 物理ホストのソフトウェアの問題
  • 物理ホストのハードウェアの問題 (ネットワーク到達可能性に影響がある)

AWS責任共有モデルのうち、AWSが責任を持つ部分の障害に自動対応してくれる仕組みということですね。

このAuto Recoveryですが、AWS利用者がどうこうできない部分で発生する障害に対してのみ発動するものですので、実際に発動するかどうかを確認する術がありません。
障害発生時にちゃんと発動するのかどうか不安ですよね。
でも安心してください、きちんと発動するんです。

今回は、過去にAuto Recoveryが発動した時の様子を書き記していきたいと思います。



障害発生状態

まず、ステータス異常発生時の貴重?な画面です。
Auto Recoveryは「システムステータスのチェック」に失敗したときにのみ発動します。

autorecovery1.png


この時点ではAuto Recoveryを有効にしていなかったので、有効にしました。そして、Auto Recovery発動。以下の画像はAuto Recoveryを有効にしてから復旧が完了するまでの一連の履歴です。
autorecovery2.png


そして、復旧完了を知らせるメール。
autorecovery3.png
このメールなのですが、アラーム設定時に指定したメールアドレスではなく、ルートアカウントのメールアドレス宛に通知されました。



Auto Recovery設定手順

Auto Recoveryの設定手順をざっくりとご案内します。以下の2ステップを実施するだけです。

  1. [EC2] - [インスタンス] - (インスタンスの選択) の後に[ステータスチェック]タブを開き、ステータスチェックアラームを作成する
  2. アラーム作成時のアクションを「このインスタンスを復元する」に設定してアラームを作成する

この手順を実施するだけでハードウェア障害時に自動で復旧してくれるのですから、基本的にはすべてのインスタンスでこの設定を実施するようにしたいですね。ただし、Dedicated Instanceなど一部Auto Recoveryが利用できないインスタンスも存在します。
現在Auto Recoveryをサポートするインスタンスタイプは、以下の通りとなりますのでご注意ください。

  • C3、C4、M3、M4、R3、R4、T2、または X1 インスタンスタイプを使用している
  • VPC (EC2-Classic 以外) で実行されている
  • 共有テナンシーを使用している (テナンシー属性が default に設定されている)
  • インスタンスのルートボリュームがEBSであること (EBS-backedインスタンス)



参考までに

Auto Recoveryについての細かい説明については、以下の資料をごらんください。
いずれもAWS公式ドキュメントです。



クロス・ヘッドのAWSサービスを見る → AWS導入支援サービス

DATE2017.03.21

【レポート】JWAS DAYS 2017 に行ってきました

みなさん、こんにちは!クラウドチームの木村です。

今回は、国内ユーザーイベントで最もアツいといっても過言ではないJAWS DAYS に行ってきたのでそのレポートを書きたいと思います!


▼会場入口JWASDAYS.JPG


JWAS DAYS とは?

本家 AWSJ 後援の元、JAWS-UG(日本の AWS ユーザーグループ)が主催する最大規模のイベントです。
今年で5回目の開催ですが、初参加の方が半数以上だったようです。
事前申込数はなんと1,700人超!その人数からもいかに注目されているイベントかがわかりますね。

公式ホームページはこちら



充実の会場設備とサービス

充電 & 休憩スペースに加え、そんな設備・サービスまで!と感心してしまう充実っぷりでした。
開催5回目ということもあり、沢山の参加者の声を反映した結果なのでしょうね。
さて、詳しくみていきましょう!


▼参加費\1,000を支払った証明となるバンド(見た目以上に頑丈!笑)Paycheck.JPG

クローク

大きな荷物、上着など預けることができます。
人も多いので熱気で暑くなるかな~と思いましたが、会場全体がひんやりしていたのでコートを来たままの人が結構多かった印象です。
コートは預けて、ひざ掛けやちょっとした羽織物を持って入るのがベターかもしれません。
懇親会は人が一堂に集まる熱気に加えお酒も入って、かなり暑かったです。


託児ルーム

事前予約でプロに託児できちゃうサービス。
これまで「子どもがいるから...」と参加を諦めていた方には本当にありがたいサービスかと思います。
現在子育て中の方はもちろん、今後子育てを経験するだろう方にとっても、こういったイベントで託児サービスが当たり前になっていければ嬉しいですね。


音声レシーバー

隣接する会場からスピーチや拍手など漏れ聞こえてくることを考慮してか、音声レシーバーが用意されていました。
しかも日本語でないセッションでは同時通訳が...至れり尽くせり。



セッション

8つの会場に分かれて開催されたセッション。
私は座談会を中心に見て回ったのですが、とても考えさせられる内容ばかりでしたのでいくつかご紹介致します。
※講義系のセッションは Slide Share でご確認いただけますので割愛します


本当の敵は社内にいる!?

~攻める情シスが吠える座談会~

ユーザー企業の情シスの皆さんによる座談会。
タイトルからかなり攻めているのがわかりますが、内容も結構な生々しさでした。

ユーザー企業における情シス部門の立場やそこで日々感じていること、社内の抵抗勢力にどう立ち向かうか等々、これまでの苦労したことや今後自分達がどうしていくべきかという意気込みを熱く語っていただきました。

新しいことを始めるにはとてつもないエネルギーを使いますし、それが周りに認められるまでには時間もかかるということを改めて認識すると同時に強く共感しました。

ただし、そういった困難を乗り越えてきた皆さんだからこそ、クラウドの恩恵を享受できたり、これまで敵かと思われた人が仲間になってくれるという少年漫画のような熱い展開が待っていたりと、沢山嬉しい経験もあったようです。
タイトルとは裏腹に、和やかな雰囲気で幕を下ろした座談会となりました。

私自身はクラウドサービスプロバイダーとして、攻めたくても攻め方がわからない、仲間が足りない、という悩みを持った中小企業の情シス担当の皆さんのご支援ができたら嬉しいなと、密かに情熱を燃やしていたのでした。


6年前のその時、クラウドで何ができたのか

~JAWSとタイガーチーム~

6年前というのは2011年3月11日、東日本大震災のことです。
福島県出身の筆者としては、色々と考えさせられる内容でした。

この時、多くのサーバーがその機能を失いましたが、日本赤十字社も例外ではありませんでした。
被災者は支援が受けられる場所を、非被災者は義援金など支援できる方法を確認するためアクセスが殺到したのです。

しかし、地震の直後にこの大混乱を予想しすぐにプロバイダーにヘルプを出した日本赤十字社の西島氏の英断によりサイトは3日で復旧したのです。
この時、ヘルプを受けてプロジェクトに当たったのがタイガーチームの皆さんです。
AWS 東京リージョンがリリースされて間もない中、AWSを選択し、仲間を集め、その後の災害支援までを行った方々の行動力と使命感に頭が下がります。

災害時、自分自身に、IT屋に、果たして何ができるのだろうか?
...3.11を機に誰もが考えたことかもしれません、そして時には無力感に襲われることもあったでしょう。
タイガーチームの皆さんも後になって「こうしておけばよかった」と思ったことが様々あったようですが、これにより救われた人が大勢いたことは事実であり、この時の教訓や感じたことを風化させないよう語っていただけることも意味のあることだと感じます。

できることは限られるかもしれませんが、私達もまずはできることから「始める」勇気が大切であり、万が一の事態に正しい知識と技術力をもって対処するという心構えが必要なのではないかと考えました。
参加することで色々な気付きがあった座談会でした。

全員で黙祷を捧げ、座談会は締めくくられました。

▼JAWS DAYS 全参加者に配布されたピンバッチ。日本赤十字社主催のプロジェクト「私たちは、忘れない。」
311バッジ.JPG


The AWS Japan Mafia トークセッション2017

第一線で活躍するエンジニアの皆さんのトークセッション。普段どんなことを考えて AWS やその他の技術と関わっているのだろうと純粋に興味があったので参加しました。
皆さん個性豊かで面白い経歴をお持ちですが、自分自身で今の業務や働き方を望んで実現してきた方のお話とあって非常に参考になるご意見が聞けました。


ランチタイムセッション

ランチタイムセッションは、16のスポンサーによって5会場で開催されました。
お弁当 & お茶も配布されますが、こちらスポンサー様からの差し入れです。ごちそうさまでした。
お昼.JPG


懇親会 & LT大会

懇親会は立食形式...いえ、大体の方は床に座っていました!笑
軽食(すぐに消えました)と飲み物をいただきながら、おしゃべりしつつLTで盛り上がるというお祭りのような雰囲気でした。

8枠用意されたLT大会は、技術・才能の無駄遣い!?と言いたくなるようなハイクオリティの発表ばかりで、思わずエンジニア魂に火がつきました。
どうでも良い情報ですがほとんどの発表者がMacユーザーだったと思います。

ゆるくて、笑えて、ためになって、いろんな方とのつながりができて、素敵な時間でした。



所感

技術者の視点から

非常に勉強になる。
企業主催のセミナーはどうしても製品プロモーションに寄ってしまうので、技術者には物足りない内容のものも多いことがしばしばあるかと思います。
一方、本イベントの発表者は企業代表というより「いちユーザー」「いちエンジニア」という立場で登壇されています。
自身の技術力を存分に発揮できるアピールの場でもあるわけですから、ためになるセッションが聴けるのも納得です。


ビジネスの視点から

ランチタイムセッションは、スポンサー企業からお弁当をご馳走していただくだけでなく、各社の採用情報や製品プロモーションを聴くことができます。
ノベルティコーナーには、AWS と相性抜群(であろう)製品のチラシも沢山置いてあり、日経クラウドファーストの特別編集版もありました。
非エンジニアの方で情報収集で来ている方も多かったようです。

また、なんとなくユーザー会って名刺交換は嫌われるかなと思っていたのですが、中にはパートナー企業を探している方や同じ悩みを持って参加している人も沢山いるので、自然と名刺交換できる場面もありました。


お祭り的な視点から

お祭り好きを名乗るほどの者でもないので、この視点で語っていいのか微妙なところではありますが...
参加者はフレンドリーな方が多いようなので、一人でおどおどしてても話しかけてもらえたりします。笑
LTを聞いているだけでも面白いですし、どんな立場であれ、AWS に少しでも触れたことのある人なら楽しめるイベントだったのではないでしょうか。


クロス・ヘッド クラウドチームの視点から

ユーザーさんの声は本当に大切だなと感じました。
AWS はユーザーの声をよく聞き、日々進化しているパブリッククラウドサービスであると言われていますが、本当にその通りだと思います。

私達のようなソリューションプロバイダーは、クラウドの選定からユーザー視点であるべきですし、お客様に心から頼っていただけるようなプロであるべきです。
そのようなことを考え、使命感で胸が熱くなるようなイベントとなりました!



以上、JAWS DAYS 2017 ご報告でした!

クロス・ヘッドのAWSサービスを見る → AWS導入支援サービス
#jawsdays