Appendix-A エンタープライズ利用にも対応できる VPCユースケース A-1 大規模環境における VPC の使いどころ A-2 VPC ピアリングを使った賢い WAF の利用方法と ログ分析 Appendix-A : エンタープライズ利用にも対応できる VPC ユースケース Appendix-A A-1 大規模環境における VPC の使いどころ Appendix-B Appendix-C TEXT: 山﨑奈緒美 この節では AWS のみならず、AWS 環境とオンプレ環境を連携するような大規模環境でも使える VPC の利 用パターンについて説明します。 VPC 利用のメリット AWS はパブリッククラウドに分類され、物理的なハード しかし、VPC を利 用することにより他の AWS ユーザー ウェアである仮想化基盤を複数のユーザーで相乗りする形 が持つ環境と論理的に分割されたネットワーク空間を利用 で利用していることになります。 できるため、よりセキュアな環境でのクラウド利用が可能と そう聞くと、他のユーザーから自分のシステムのデータを 盗み見られてしまうことになるのでは？と思われるかもし れません。 確かに AWS で EC2 が出てきた頃は現在では EC2Classic なっています。 現在では新規アカウント作成時にデフォルト VPC が作成 され、ユーザーが意図的にデフォルト VPC を削除しないかぎ りは EC2 や RDS などのインスタンスは VPC の中に作成され と呼ばれる環境があり、セキュリティグループの設定が甘い ることとなります。 場合にはそのようなリスクはありました。 ※ 2013 年 12 月 4 日以降に作成された AWS アカウントでは EC2Classic は 利用できず、VPC のみを利用するような形となっています。 DirectConnect 利用によりクラウドを第二のデータセンターへ AWS 上だけで全てが完結するシステムを構築・運用する AWS では VPC とインターネット VPN を利用した接続を 場合は気にしなくても良いことではありますが、AWS 上に することも可 能ですがインターネット VPN を利 用する場 社内システムや外部公開しているシステムであってもバッ 合、接続断が DirectConnect よりも頻繁にあることを前 クオフィス利用が発生するようなシステムを構築・運用して 提にネットワーク設計を行ったり、セキュリティや通信品 いる場合、社内からの通信に対するセキュリティの担保とい 質、帯域のスループット、通信経路がインターネット越し う部分が AWS を利用する上での第二のポイントとなるかと となるため、通信経路コストがかかるといった点があり、 思います。 DirectConnect を利用する場合はこれらの課題をクリアす 専用線を使用した閉域網接続である DirectConnect を利 ることができます。 用すると、社内と AWS 間の通信接続自体も物理的または論 それにより、ユーザーとしてはオンプレミス環境のデータセ 理的に隔離された環境での接続となるため、よりセキュアに ンターに接続しているのと変わらない感覚で、AWSを利用し AWS 環境の利用ができることとなります。 ているということを意識せずに利用することができます。 002 A-1 大規模環境における VPC の使いどころ オンプレ環境とのハイブリッド環境での利用 現在の日本国内の企業では全システムが AWS 環境にあ インターネット公開している WEB サーバーのグローバル IP り、データセンターやオンプレミス環境を一切使用していな アドレスとすることでオンプレミス環境の WEB サーバーが いという企業はまだまだ少ないのではないかと思います。 利用するドメインをRoute53でホストすることができます。 既存システムのハードウェアの保守契約や減価償却の関 これにより、わずらわしい DNS サーバーの管理をするこ 係上、まだまだオンプレミス環境のデータセンターにシステ とがなくなり、アクセス集中時等に DNS サーバーへの DNS ムがあるといった企業も多くあります。 問合せによる負荷高騰といったこともなくなります。 また、現在データセンターにあるシステムを AWS 環境へ 移行している途中という企業もあるかと思います。 既存のオンプレミス環境のシステムと AWS のサービスや AWS Directory ServiceとRoute53を利用してVPC内リソー スの名前解決 システムとを組み合わせて利用することをハイブリッドク Route53 でインターネット公開しているオンプレミス環 ラウドと呼びます。 境の WEB サーバーの名前解決について紹介しましたが、イ ここでは典型的なハイブリッドクラウドの例を紹介し ます。 ンターネット側からの名前解決だけではなく、社内のクライ アント PC やオンプレミス環境にあるサーバーから VPC 内に ある EC2 インスタンスや RDS などの名前解決、またはその 逆方向の名前解決を行うことも可能です。 Route53 利用パターン クライアントPCやオンプレミス環境からAWS側のリソー AWSではRoute53というフルマネージドのDNSサービス スの名前解決を行う場合、単純にオンプレミス環境にある があり、 Route53のみを利用している企業も多数あるようです。 DNS サーバーで EC2 インスタンスのプライベート IP アドレ スを A レコードで作成したり、RDS のエンドポイント URL オンプレミス環境の WEB サーバーを Route53 でホストする Route53 でゾーンの作成をしてドメインの設定をし、A レコードの名前解決先の IP アドレスをオンプレミス環境で を CNAME で作成することでも可能ではありますが、ドメイ ンおよびレコードセットも Route53 で管理したいとなる場 合、一つの制約が出てきます。 オンプレミス環境の WEB サーバーを Route53 でホスト 003 Appendix-A : エンタープライズ利用にも対応できる VPC ユースケース Appendix-A Route53 でプライベートゾーンを作成し、VPC 内から名 バーの IP アドレスで設定します。 前解決を行う場合 EC2 インスタンスなどの VPC 内にあるリ また、EC2 インスタンスによってはオンプレミス環境の ソースは、VPC 内に作成される VPC Provided DNS を経由 リソースに対する名前解決の必要のないものもあるかと思 することによって名前解決を行います。 います。 Appendix-B Appendix-C ただし、VPC Provided DNS は VPC 外からの DNS クエ リには応答しないため、直接クライアント PC やオンプレミ その場合はインスタンスの DNS 設定はインスタンス起動 時そのままとすれば VPC Provided DNS のみを参照します。 ス環境のサーバーから名前解決を行うことはできません。 そこで AWS Directory Service を利 用して Route53 の プライベートゾーンのレコードセットへの名前解決を実装 S3 を利用したファイルバックアップ します。 AWS Directory Service へ の DNS ク エ リ は VPC Provided DNSを経由してRoute53の名前解決を行います。 このため、AWS DirectoryService で SimpleAD もしく は MicrosoftAD を作成し、オンプレミス環境にある DNS は フォワーダーとして DNS クエリを AWS Directory Service うちの会社では大層なシステムなんて持っていないし、わ ざわざ AWS を利用するまでもないといった企業でも、NAS ぐらいは社内に設置されているのではないでしょうか。 NAS の運用で一番頭を悩ませることとして、バックアップ の問題があります。 へフォワードするように設定すると、クライアント PC やオ どこまでバックアップを保存すればよいのか、そのための ンプレミス環境のサーバーからの名前解決ができるように バックアップ用の領域の確保であったり、エンタープライズ なります。 向けの高機能な NAS ではなく家電量販店で購入できるよう 逆に VPC 内にある EC2 インスタンスからオンプレミス環境 な NAS を利用していて、バックアップ用に NAS をもう一つ のサーバーなどの名前解決を行いたい場合はどうでしょう。 用意している場合でも、なぜかバックアップ用の NAS が先 上記の環境をまず構築し、EC2 インスタンスで利用する に壊れ、それに気づかず本番用の NAS が壊れた時に初めて DNS サーバーの IP アドレスをオンプレミス環境の DNS サー バックアップ用NASが壊れていることに気が付く・・・といっ AWS Directory Service と Route53 を利用した VPC 内リソースの名前解決 004 A-1 大規模環境における VPC の使いどころ た NAS のバックアップについてはあるあるネタが満載かと 思います。 DirectConnect や VPN 接続で VPC をオンプレミス環境 を接続している場合、WEB サーバーを EC2 インスタンスで 最近では家電量販店で販売しているような NAS でもバッ クアップを S3 にアップロードできる機能を NAS の管理画面 で設定できる機種も販売されています。 イレブンナイン、 99.999999999%の堅牢性を誇るS3へファ イルバックアップがお手軽にでき、バックアップしたファイ オートスケーリングするように設定しておくと、このような システム構成を構築することも可能です。 また、WEB サーバーも DB サーバーもオンプレミス環境 で運用しているが、キャンペーン時のみ EC2 インスタンスで WEBサーバーを増やしたいといった要件にも対応できます。 ルの世代管理が楽にできるというメリットがあります。 スケーリングが要求される部分のみ AWS へ切り出す システム要件によって WEB サーバーは AWS、DB はオン プレミス環境に置きたいという場合もあるかと思います。 WEB サーバーのみ AWS へ切り出した方式 005 Appendix-A : エンタープライズ利用にも対応できる VPC ユースケース Appendix-A VPC の利用パターン VPCを利用するにあたってさまざまな利用方法があります。 システム種別および環境種別による VPC 分割パターン どのパターンでもメリットにもなりデメリットにもなる システム別に AWS アカウントを分けてその中で本番用 Appendix-B Appendix-C ため、AWS をどのように使用したいかによってパターンを 選択すると良いかと思います。 次に代表的な VPC の利用パターンを紹介します。 VPC と検証用 VPC、開発用 VPC と分割するパターンです。 アカウントが違うため 1 システムあたりの費用がアカウ ントに対する請求の金額そのままになるため、システムごと の費用按分をする必要もなく、各環境が相互に影響を与える こともなく利用ができます。 単一 VPC パターン VPC の CIDR ブロックは最大で /16 で作成することができ ます。 一つの大きな VPC を作成し、その中でサブネットを /24 や ただし、共通システムや他システムとの連携を行うため に VPC Peering を行う場合、VPC で利用する CIDR ブロッ クの重複や対向している VPC とさらに接続している VPC へ の接続ができないため、連携するシステムが多数ある場合、 /26 などの CIDR ブロックで分割することにより、VPC 自体 VPC Peering の数も増えてしまうため VPC Peering の構成 をオンプレミス環境のデータセンターを利用する感覚で利 が複雑化することになります。 用することとなります。 一つの VPC で全ての AWS リソースを管理することになる ため、AWS 上のシステム同士での連携や DirectConnect また、リザーブドインスタンスは AWS アカウント間で共 有ができないため、購入したリザーブドインスタンスが余っ てしまった場合無駄になってしまうこととなります。 やVPN接続も一つのVPCのみとシンプルな接続となるため、 一見単純なように見えますが VPC 内のシステム環境やサブ ネット利用ポリシーをあらかじめしっかりと設計していな いと複雑化しやすくなってしまいます。 また、システムごとに費用按分を行う場合、リソースへの タグ付けをしっかりと行う必要があります。 どのような VPC パターンを選択するか VPC やアカウントの利用パターンを挙げましたが、どのパ ターンを利用するかは既存オンプレ環境や拠点ネットワー ク等の全体のネットワーク設計にも関わってくるため、企業 ごとに様々なパターンを選択することとなります。 また、アカウントや VPC を分ける場合にネットワークアド 用途による VPC 分割パターン 本番用VPCと検証用VPC、開発用VPCといった用途によっ て VPC を分割して利用するパターンです。 論理的に別の空間での利用となるため、各環境が相互に影 響をあたえることがなく利用することができます。 しかし、単一 VPC パターンと同様に本番環境に複数のシ ステムがある場合には費用按分の課題は残ります。 レス帯が重複せず、VPC ピアリングができるようにあらか じめ設計しておくことも重要です。 AWS 費用計上が部門別となる場合にはアカウントを部門 ごとに分けるようにすると、費用按分の手間が省けて請求処 理も楽になります。 クラウドという管理や運用の手間を最小限にできるサー ビスを使うのですから、構成が複雑になってしまって管理の 手間が増えた、引き継ぎに時間がかかる、といったことのな いよう、クラウド利用の良い所を活かせるようにしていくと 良いでしょう。 006 A-2 VPC ピアリングを使った賢い WAF の利用方法とログ分析 A-2 VPC ピアリングを使った賢い WAF の利用方法と ログ分析 TEXT: 吉江瞬 この節では、先述した AWS のサービスを色々と用いて、より AWS 上にセキュアな仮想ネットワークを構築 することを考えてみます。特に CDP:Shared Service パターンに沿った形で、しかし、単に仮想ネットワー クをセキュアにしただけではないことを考慮して記載したいと思います。 WAF の利用 何をセキュアに守るかということを考えた上でそれが のため、WAF が監視する対象サーバーでは、HTTP/HTTPS WAF であるという結論にいたった場合、その WAF をいかに を受けつけるサーバーがいることが当たり前です。その 効率よく導入し、運用できるかが必要となってきます。WAF WAF を必要な数だけ理想の形で導入するには、CDP: WAF は従来の Firewall や IDS/IPS では防ぐことのできない攻撃 Proxy パターンと CDP:Shared Service パターン、この２パ から Web アプリケーションを防 御するものです。HTTP/ ターンを満たす形で WAF を導入することです。 HTTPS に関するリクエストとレスポンスを監視します。そ WAF 専用 VPC と SIEM 007 Appendix-A : エンタープライズ利用にも対応できる VPC ユースケース Appendix-A WAF 専用 VPC の用意 Appendix-B Appendix-C 前ページの図のように共同で利用できる WAF 専用の VPC Application Firewall が あ り ま す。BYOL/On-Demand を用意し、その VPC に対して WAF 監視対象とするサーバー のいずれの形 式でも提 供されています。この WAF を利 用 が属する VPC が VPC Peering 接続をするという構成です。 すれば、Auto Scaling にも対応した WAF の導入が可能と オンプレミス環境から各種 VPC までは VPG との VPN 接続 なります。また、最近は Sophos 社の UTM 9 Autoscaling でも、DirectConnect を使った専用線接続でも、所属する Web Application Firewall や Barracuda Networks 社の 企業ポリシーによって選択いただければと思います。WAF Barracuda Web Application Firewall も Auto Scaling はリバースプロキシ型であり、VPC Peering 先のサーバー に対応した WAF を提供し始めています。企業としての利用 までリクエストを渡します。たとえば、企業の部門ごとに であれば、これらサードパーティ製 WAF を利用するのはサ VPC が作られていたのであれば、WAF 専 用 VPC は企 業で ポートも行き届いていて良いと考えます。導入コストをもっ 一元管理する形を取ることができます。WAF 監視対象とす と下げたいという場合は、無償の WAF を利用することも検 るサーバーが増えるとそれ相応のトラフィックに対応でき 討してみましょう。たとえば、OWASP にて開発が進められ るような構成、まして Web サーバーが Auto Scaling する ている Mod_Security があります。ただし、これらは Auto のなら、WAF も Auto Scaling させたいところです。近年 Scaling に対応しているわけではないため、スケールするイ のサードパーティ製 WAF には Auto Scaling に対応してい ンスタンスに自動で設定されるようにする必要があります。 るものがありますが、もっとも早い時期に Auto Scaling に 対応した WAF としては Imperva 社の SecureSphere Web WAF の運用 WAF は導入したらそれで終わりというわけにはいきませ いものは遮断とするその確認期間をチューニング期間とい ん。WAF で検知するログの内容から、通すべきものは通す、 います。このチューニング期間が終わってからも、今後更新 止めるべきものは止めるというように WAF そのものを運用 される WAF のシグネチャの適用や、新たに Web アプリケー する必要があります。WAF の管理画面から WAF の通信内容 ションをリリースするといった場合の誤検知除外対応など、 を確認し、リクエストの内容を詳細に確認し、誤検知してい WAF の運用は長く付き合っていく必要があります。 るものは除外、検知のみとしたいものは検知のみ、遮断した 008 A-2 VPC ピアリングを使った賢い WAF の利用方法とログ分析 ログ分析と SIEM WAF による検知ログや遮断ログ、サーバーへのアクセス 理想とする権限やルールを設定することができます。 ログだけでなく、その他 AWS のサービスの取得が可能なロ 逆に、想定外の認証が行われた場合にアラートを発生 グがもたらしてくれる恩恵が大きなものとなる考え方をお させるということも考えることができます。 伝えしたいと思います。読者の皆さんは、SIEM というキー ワードをご存知でしょうか？ SIEM(Security Information • CloudTrail：AWS CloudTrail は IAM アカウントに対す and Event Management) はセキュリティに関する統合ロ るあらゆるイベントをログに記録します。IAM アカウ グ管理ツールであり、ログデータの集約や正規化、ログとロ ントが行った AWS API 呼び出し元の ID、API 呼び出し グの相関分析によって、異常とみられるイベントが見受けら 元のソース IP アドレス、リクエストのパラメータ、お れたとき、リアルタイムでアラートを発し、視覚的に分かり よび AWS サービスから返された応答が含まれるため、 やすくしてくれます。インシデントレスポンスを行う企業 監査の観点からも有効といえるこれらのログはセキュ ではしばしば用いられているツールや概念となります。ロ リティイベントを管理するにおいて必要不可欠です。 グを全て人目で追うには限界があるため、可能な限り得ら れるログを元に、SIEM を用いて相関分析を行い、インシデ • CloudWatch Logs：Amazon CloudWatch Logs は ントレスポンスの初期対応を始め、WAF のチューニング、 CloudWatch の拡張された機能で、EC2 インスタンス Security Group の要件見直し等を図るのに役立ててもらえ のログ、たとえばアプリケーションログやシステムロ るのがよいと考えます。このようなログ分析を行うのに HP グをリアルタイムにモニタリングすることが可能とな 社の Arcsight や IBM 社の QRadar は有 名ですが、AWS で ります。また、CloudTrail のログをモニタリングする の利用が可能な Splunk 社や Sumo Logic 社の製品を利用 ことも可能なサービスですので、簡単なフィルタリン するユーザーも近年は増えているように見受けられます。た グ設定とアラート設定を本機能で行うことで SIEM ラ とえば AWS のサービスの中では以下のようなログは有効活 イクなことを実現することが可能です。 用できるものと考えます。 • VPC Flow Logs：VPC Flow Logs は VPC 内 の Network • IAM(Identify & Access Management)：IAM はユーザー Interface 間の IP トラフィックをログとして保存でき ごとに AWS リソースの使用に関する認証、リソース ます。送信元および送信先の IP アドレスだけでなく、 の利用方法に関する承認を行うことができます。ユー ポートやプロトコル番号や許可 / 拒否したかも確認す ザー、グループ、ロール、ポリシーを利用することで、 ることができます。 009 Appendix-A : エンタープライズ利用にも対応できる VPC ユースケース Appendix-A SIEM による相関分析 たとえば、 Management Console や CloudTrail にて確認するべきでしょ う。それはあなたが管理している AWS 上の IP アドレスか Appendix-B Appendix-C • WAF では検知のみのログ もしれない。または、AWS を利用する他社サービスがマル • VPC Flow Logs のアクションは許可 ウェア感染をしているがために、不正アクセスをしてくる • CloudWatch Logs で示されるサーバーのステータス という可能性もなくはないでしょう。緊急遮断ができない コードが 200 といった場合はそのサービス提供元管理者に確認すること も必要となってきますね。最近ではブラックリスト IP アド が確認された場合に SIEM でアラートをあげます。不正アク レスが API で公開されているものも存在します。これらと セスを行ってきた送信元があからさまに怪しい送信元であ 組合せることで、各種システムから出力される大量のログ ることを確認できた場合、WAF や Security Group での遮断、 を統合し、ログの相関分析により不正アクセスを検出させ サーバー側のアクセスログを確認することが必要となりま ることができるでしょう。クラウド電話 API 等を利用する す。もし、送信元が Amazon Web Services からの IP アドレ ことで、少ないリソースでもインシデントレスポンスを実 スであった場合、本来は早急に遮断してしまいたいところ 現することもが可能になると考えます。 ですが、この IP アドレスが何に利用されているのかを AWS 010 Appendix-B IoT とモバイルネットワークの未来 に触れる B-1 IoT を取り巻く環境の変化 B-2 IoT プラットフォームを狙うモバイル通信 B-3 IoT 時代のクラウドエンジニア像 Appendix-B : IoT とモバイルネットワークの未来に触れる Appendix-A B-1 IoT を取り巻く環境の変化 Appendix-B TEXT: 片山暁雄 この節では、IoT にフォーカスを当て、なぜ今 IoT が取り上げられているのか、近年の IoT を取り巻く環境の Appendix-C 変化について説明します。 投資とビジネスモデルとのミスマッチの解消 IoT をテクノロジーの側面でとらえた場合、B3G/LTE な 験を必要がありますが、従来ではそもそもサーバーやデバ どデバイスのデータを集めるための通信技術は、以前より利 イスの初期コストが高かったり、プロトタイプのシステムと 用することができました。 して一通り稼働するものを完成させるための技術者確保が またデータを分析するためのアプリケーションも、以前よ り利用することは可能でした。しかしながら、従来は取得し ていなかったデータを収集して、意味のある情報を見つけ、 難しく、限られた期間や予算では実現が困難という状況が ありました。 しかしながら近年、クラウドと通信、そしてデバイスの進 製品や顧客サービスへの還流によって利益を上げられるよ 化により、この検討フェーズにおける先行投資やテクノロ うにするためには、トライアンドエラーを繰り返し、ビジネ ジーの敷居が非常に下がってきており、新しいビジネスモデ スモデルとして成り立つにはどうしたら良いかを検討する ルを作るための投資が非常にしやすくなっており、企業の ための検討フェーズが必要となります。 IoT に関する取り組みが活発になり、それに合わせて IoT が この検討を行うためには先行投資として、様々な実証実 大きく取り上げられるようになっています。 AWS クラウドが推し進めた IoT インフラのコモディティ化 IoT と相性の良い AWS の特性 ありません。 ここまでの章で、数多くの AWS サービスの説明がありま また実 際に数 多くの機 器とデータの交 換をすることに した。そのサービスは、EC2 や S3、VPC といったインフラ なった場合や、一時的に収集したデータを解析するような場 レイヤーに近いものから、Amazon Cognito や Amazon 合になったとしても、必要に応じてスケールアップすること Elasticsearch Service のようなアプリケーションレイヤー ができます。 のものまで、幅広く提供されています。 これらは初期費用なしの従量課金で提供されるため、トラ イアンドエラーを繰り返す IoT の検討フェーズには非常に マッチします。従量課金自体も安価であるため、データを保 存する際に容量を気にしてデータを間引いたりする必要も 012 こういった AWS クラウドの特徴は、特にトライアンドエ ラーを繰り返す必要のある IoT と非常に相性が良い、という ことになります。 B-1 IoT を取り巻く環境の変化 作ることが「競争力」から「リスク」に変化 初期費用なしの従量課金、という費用的なメリットの他 に、AWS クラウドの普及により、様々な IT インフラを「構 築済みで運用も行ってくれるサービス」として利用できるよ うになりました。 従来との比較 従来であれば、大規模なインフラを構築しそれを運用でき るリスクとなる可能性もあります。 ること自体が競争力となっていましたが、AWS を利用する たとえば AWS IoT を利用しビジネスロジックのみに専念 ことでこの優位性はなくなり、企業 / 個人問わず同じサービ して実証実験を行うのと、AWS IoT で提供される機能（認 スを利用できるようになり、IoT インフラそのものはコモ 証や Device Shadows など）を 1 から構築してから実証実 ディティ化し、ビジネスにおける競争力の源泉ではなくなっ 験をするのでは、成果のアウトプットまでに大きな差が出る てきています。むしろ AWS が提供しているサービスであれ のは、容易に想像できるでしょう。 ばそれを積極的に利用しないと、費用や時間に無駄に投資す 013 Appendix-B : IoT とモバイルネットワークの未来に触れる Appendix-A デバイスの進化 低価格 / 高性能のデバイス Appendix-B IoT では、現実のデータを取得し、またクラウド上で行った 分析結果をフィードバックするために、デバイス側の開発も 当然必要となってきます。 従来であれば、専用の開発キットや言語が必要なマイコ Appendix-C ンを利用したりしていましたが、最近では Intel Edison や AWS でもこういったニーズをとらえ、「IoT Starter Kit Powered by AWS」という名称で、いくつかのデバイスを販 売しています。 • Intel® Edison and Grove IoT Starter Kit Powered by AWS http://www.amazon.com/dp/B0168KU5FK Raspberry Piなどのプロトタイプ作成に向いたシングルボー ドコンピューターを安価に入手し、利用できるようになって います。 ま た こ う い っ た シ ン グ ル ボ ー ド コ ン ピ ュ ー タ ー は、 GPIO(General Purpose Input/Output) や I2C といった また AWS のパートナー 制 度である「Amazon Partner Network」でも、クラウドではなく IoT 向けデバイスを提供 する APN テクノロジーパートナーという枠が設定され、日 本ではぷらっとホーム株式会社が認定されています。 各種センサーと接続するためのインターフェースを備え、 さらにこれらのインターフェース経由で値を取得する際に も、JavaScript(Node.js) や Python などいったクラウド • https://aws.amazon.com/jp/solutions/solutionproviders-japan/technology-partners/iot-devices/ 上での開発で馴染みのある言語用の API やライブラリを利 用することができるため、まずは動くものを作ってトライア ンドエラーを手早く行うというような目的には非常にマッ このようにして、クラウドが一つの契機となり、IoT を取 り巻く環境はここ数年で大きく変化しています。 チします。実際に、AWS Summit 2016 Tokyo では、日本 2020年には、500億から1000億のデバイスがインターネッ 電産株式会社がプレス金型の温度分布を AWS で解析し、不 トにつながるともいわれており、向こう数年はこの IoT の大 良品率を改善するというトライアルを 2 週間で行ったとい きな流れにより、新しいビジネスやサービスが出てくること う発表がされています。 が予想される、 注目度の高い領域といえるでしょうか。 014 B-2 IoT プラットフォームを狙うモバイル通信 B-2 IoT プラットフォームを狙うモバイル通信 TEXT: 片山暁雄 前節では、クラウドとデバイスの進化とコモディティ化により、IoT システムの構築の敷居が下がってきて いることを紹介しました。 それでは、 クラウドとデバイスを接続するネットワーク部分は現在どのような状況なのでしょうか。 モバイル通信の利点 IoT システムを構築する場合、クラウドをデバイスを接続するために、幾つかの選択肢があります。 SIM カード たとえば有線 LAN は、ネットワーク帯域も広く、一度敷設 してしまえば運用コストは安価になります。 しかしながら、有線 LAN が敷設できる場所は限られてお り、デバイスを配置する場所が限られてします。 えば、運用コストは安価になります。しかしながら、デバイ スを配布するプロセスを考えた時、無線 LAN に接続する設 定が問題になる場合があります。たとえば 100 の出荷先が あり、それぞれに異なる ID/ パスワードで無線 LAN に接続す また自動車などの移動体には接続できません。 る必要がある場合には、事前に ID/ パスワードを収集してデ では無線 LAN ではどうでしょうか？場所の制約について バイスに設定して出荷するか、もしくは出荷後に設定を行っ は、有線 LAN よりも自由ですし、無線 LAN も一度敷設を行 て貰う必要があります。 015 Appendix-B : IoT とモバイルネットワークの未来に触れる Appendix-A またこういった手間を省くために、同一の ID/ パスワード を利用してしまうと、これが漏れた時に出荷したすべてのデ バイスの ID/ パスワードの変更が必要となり、実際の運用で Appendix-B は非常に手間がかかります。またもちろん、無線 LAN がない 場所や自動車などでは利用することができません。 トワークのカバー範囲も広いため、自動車などの移動体でも 利用することができます。 さらにモバイル通信では、通信者を確認するために SIM カード ( 利用者認識カード）を使用します。 この SIM カードの中には、ID と通信を暗号化するための Appendix-C 有線 LAN、無線 LAN の欠点を考えると、携帯電話やスマー 鍵が入っています。ID も鍵も SIM カードごとにユニークに トフォンで利用している 3G/LTE のモバイル通信は、IoT に なっており、モバイル通信をする場合にこれらを使用して認 向いています。 証と暗号化が行われるため、デバイス側で意識をしなくとも 一つは通信設定の容易さです。モバイル通信の場合、一度 セキュリティを高めることができます。 設定をすれば、日本全国どの場所でも接続できますので、デ しかしながら有線 LAN や無線 LAN と比べると、通信費用 バイスの出荷先や設置先にによって通信設定を変える必要 や通信モジュールの費用が高い、という問題があるのが現状 がないため、初期設定や管理が非常に楽になりますし、ネッ です。 SIM カード 016 B-2 IoT プラットフォームを狙うモバイル通信 モバイル通信の動向 次世代の規格 IoT のシステムを構築にモバイル通信を利用する利点は多 くありますが、先ほど述べたとおりで通信料や通信モジュー ルの問題があります。しかしながら、通信ベンダー / 通信デ は異なる周波数を使って、モバイル通信の使えないエリア もカバーできるような LoRa や Sigfox と言った規格も策定 されてきています。 こういった規格は通信速度が上り下りとも 1Mbps 以下と バイスベンダー各社はこの問題に取り組みをはじめており、 なっており、通信速度以外にも、通信を行うための基地局と IoT 向けに利用しやすい LTE の規格が、幾つか策定されてい の定期的な通信を省略する機能や、上りもしくは下りだけし ます。 か利用しない機能などを備え、消費電力を極力減らすような 通常、スマートフォンやモバイルルーターで利用している LTE は、多くが「カテゴリー 4」と呼ばれる規格を使用してい ます。 工夫がされています。 たとえば 1 日 1 回数百バイトの送受信をするのであれば、 2500mA(iPhone6s Plus が 2740mA) のバッテリーで 19 年 カテゴリーにより、通信速度や必要なアンテナ数、変調方 間通信できる、という試算などもあります。もちろんサイズ 式などが異なり、たとえばカテゴリー４の場合は、通信速度 や価格も、カテゴリー 1 よりもさらに小型 / 低コストになる は上り最大 50Mbps、下り最大 150Mbps の高速通信となっ ことが見込まれています。 ています。 これに対して、「カテゴリー 1」と呼ばれるカテゴリーの場 合、上り最大 5Mbps、下り最大 10Mbps となっています。 デフォルトでモバイル通信ができる時代に カテゴリー 4 と比較する通信速度は劣るものの、IoT 用途 IoT 向けのモバイル通信規格が普及し、数百円台でモバイ を考えると十分ですし、カテゴリー１はカテゴリー 4 よりも ル通信用の機器が調達できるようになると、様々なモノにモ 通信デバイスの処理が簡単になるため、デバイスの小型化や バイル通信機器が当たり前のようにつく時代になることが 消費電力の低減、低コスト化が見込まれています。 予想されます。 既に NTT ドコモはこのカテゴリー 1 の導入準備を進めて います。 またさらに、より IoT 用途に特化した「カテゴリー M」や 「NB(Narrow Band) LoT」と呼ばれる規格、さらには LTE と 今までは費用やデバイスサイズ、消費電力などで難しかっ た様々なモノがネットワーク接続ができるようになり、デー タを収集 / フィードバックできるようになると、あらゆる産 業で IoT が活用されるでしょう。 017 Appendix-B : IoT とモバイルネットワークの未来に触れる Appendix-A B-3 IoT 時代のクラウドエンジニア像 Appendix-B TEXT: 片山暁雄 これからより多くのビジネスが見込まれる IoT にエンジニアとして取り組む場合、どのようなスキルや経験 Appendix-C が必要なのでしょうか？この節では IoT 時代のエンジニア像について掘り下げてみたいと思います。 IoT 時代のエンジニア像 IoT ビジネスにおいては、AWS を含めたクラウドプラッ 最近では Raspberry Pi や Arduino などを手軽に利用す トホームやクラウドサービスを利用することは、必須といえ ることができますが、実際に IoT デバイスを使ったビジネス るでしょう。前節でも紹介したとおり、IoT はビジネス的に を考えた場合、デバイスの大きさやコスト、運用などを考え もテクノロジー的にも日進月歩の領域であり、ビジネスがう ると、そのままビジネス化をするのは難しい場合も多いと思 まくいくかどうかを試行錯誤しながら進めて行く必要があ います。 ります。このため、インフラ構築などに時間やコストを使う しかしながら、これらのデバイスを使って実際に手を動か ことはどんどん難しくなります。このため、AWS やその他 してネットワークに繋げ、AWS のサービスと連携してみる クラウドサービスが提供しているサービスを自分が目指す ことで、「デバイスが 1000 台になったときに、初期設定は ビジネス実現に対して如何に当てはめていくか、というスキ 楽にできるのか」 「デバイスごとにユニーク ID を振らないと ルは必ず必要となります。 クラウド上でデータを分けられないけど、どうすればいいの また単にクラウドサービスを知っているだけではなく、実 か」 「パスワードはどこにおけばいいのか」 「通信間隔やタイ 際に手を動かして構築するハンズオンスキルも必要です。時 ミングはどうしたらいいのか、通信が切れたどうしたらいい 間やコストをかけずにプロトタイプを構築することができ のか」など、今まででとは違う視点を持つことができますし、 れば、検証実施を行うまでの期間を大きく減らすことができ こういった経験は実際にビジネスで IoT システムを作る際に ますし、トライアンドエラーも繰り返すことができるように 役に立つでしょう。 なります。 最 近では、AWS のユーザーグループでもある JAWS の またプロトタイプを構築することを考えると、クラウドだ IoT 支部や、AWS 上で AP 操作可能なモバイル通信を提供し けでなくモバイル通信やデバイスについても知識があるこ ている SORACOM などが、ハッカソンやハンズオンを盛ん とが望まれます。 に行っています。 少なくとも、どのような通信やプロトコルがあるのか、デ バイスはどのように動作するのか、センサーはどのように接 続するのか、などを知ることで、IoT システムを作る際には 大きなプラスとなります。 018 B-3 IoT 時代のクラウドエンジニア像 ハンズオンの様子 ハンズオン機材 また大阪ではユニークな取り組みを行っており、4 つの ループベースのハンズオンとはいえ、ハンズオン資料や設備 ユーザーグループ（関西おうちハック、SORACOM-UG 関西、 も有志により整えてありますので、是非足を運ばれることを JAWS-UG 関西 IoT 専門支部、kintone Café 大阪）が共同 おすすめします。 で IoT リレーハンズオンを行ったりしています。ユーザーグ 019 Appendix-B : IoT とモバイルネットワークの未来に触れる Appendix-A 新しいビジネスに対するアーキテクチャ Appendix-B この章で説明したとおり、クラウド、通信、デバイスの発展 ス（たとえば VPC ピアリングや S3 のクロスアカウントアク と低価格化、コモディティ化により、クラウドに閉じたシス セスなど）を利用することで、専用線などを用意しなくても テムから、現実のモノとつながって価値を生み出すようなシ AWS 上だけで瞬時にデータ交換を行える仕組みを作ること ステムが増えて来ることが予想されます。 ができます。これは既存のオンプレミスやデータセンターで そのシステムは、今までとは異なるアーキテクチャ、運用、 Appendix-C セキュリティが必要になってきます。 また今まででは取れなかったデータがモノからクラウド に集まりだすと、データ自体がビジネス価値を持ち始め、1 はできなかった、画期的なものだと考えます。 今後はこういった可能性も視野に入れながら、アーキテク チャを作っていく必要があります。 いずれにせよ、AWS クラウドを使いこなすことができ、 つの企業に閉じず、異なる業種の企業間のデータ連携が盛ん その上でビジネスや新しいアーキテクチャに目を向けられ になる可能性があります。 るエンジニアにとっては、大きなチャンスとなるでしょう。 AWS を使う企業は、どの企業であっても AWS のサービ 020 Appendix-C Cloud ならではの大規模 CPU の利用 C-1 キャンペーン・セール特設サイト向きな事前スケー ルアウト C-2 オンプレで処理しきれなくなったバッチを AWS に オフロードして処理を実行 Appendix-C : Cloud ならではの大規模 CPU の利用 Appendix-A C-1 キャンペーン・セール特設サイト向きな 事前スケールアウト Appendix-B TEXT: 山﨑奈緒美・中丸良 Appendix-C AWS ならではの利用方法としてインスタンスのスケールアップ・ダウンとスケールアウト・インというもの があります。スケールアップ・ダウンとは 1 つのインスタンスに割当てている CPU やメモリ量を増やしたり 減らしたりすることを指し、スケールアウト・インとはスケールアップ・ダウンとは違ってインスタンスの数 を増やしたり減らしたりすることを指します。 AutoScaling の概要 EC2 インスタンスの CPU やメモリ使用量やアクセス状況 WEB サイトに使用している WEB サーバーやゲームに使用 を CloudWatch で監 視し、CloudWatch でしきい値を超 しているアプリケーションサーバーに AutoScaling を設定 えた際にトリガーを設定することによって EC2 インスタン することにより、サーバーに対するアクセスが増えてリソー スのスケールアウト・インを自動的に行うようにする仕組み ス負荷が高くなった際にスケールアウトをさせるというの を Auto Scaling と呼びます。 は有名な使用方法となります。 キャンペーン・セール特設サイトの特性 AutoScaling はサーバーのリソース負荷が高くなった際 LINE などによる広告を打つことが多く、その際のサイトへ に自動的にサーバーインスタンスを増やすことによって各 のアクセスの増え方として広告配信完了直後から急増する サーバー単位の負荷を分散させるという意味で有効な手段 パターンが多くあります。 となりますが、逆にデメリットも有ります。 そして、広告配信後 5 分間でアクセス増のピークを迎え、 CloudWatch の監視間隔が 1 分間ごととなっており、し 10 分〜 15 分後にはアクセスが落ち着くというパターンが きい値を超えたことを検知してから AutoScaling が発動し ほぼとなるため、起動しきるまでに 10 分〜 15 分ほどかかる EC2 インスタンスを起動させるのですが、EC2 インスタン AutoScaling でのスケールアウトでは対応しきれない状況 スが起動してアクセスを受け入れられるようになるまで約 5 となります。 分〜 10 分ほどかかることとなります。 昨今では EC サイトや企業の商品サイトなどでキャンペー ンやセールの特 設サイトを設けて Twitter や Facebook、 022 このような急激かつ短時間で収束するアクセス増に対応 するための手法を紹介します。 C-1 キャンペーン・セール特設サイト向きな事前スケールアウト どのような準備が必要か 企業が主体となってキャンペーンやセールの広告配信、ま このため、 それらの部門との連携を密に取る必要があります。 たはテレビやラジオ放送を行う場合、広告配信やテレビ放送 どのような媒体で、いつ広告配信やメディアでの放送が行 が行われるタイミングは事前に広報部門やマーケティング われるのか、各部門から事前に、遅くても 3 日前までには連 部門などが把握していることがほぼであると考えられます。 絡をもらえるようにしましょう。 EC2 スケジュール起動 予めスケールアウトさせておくべき時間が確定したら、 EC2 インスタンスのスケジュール起動の設定を行います。 注意事項として、EC2 インスタンスが起動するまでにか かる時間の考慮が必要となります。 せるインスタンス数の指定および繰り返しパターン、開始時 刻、終了時刻を設定します。 開始時刻は UTC( 世界標準時 ) となるため、日本時間から 9 時間をマイナスした時刻を入力します。 繰り返しパターンの設定は一度のみのパターンや Cron 形 式での設定など、 柔軟なパターン設定を行うことができます。 AutoScaling による時刻起動 既に EC2 インスタンスを AutoScaling 設 定している場 合、AutoScaling グループでスケジュ ール起 動させたい AutoScaling グループの「スケジュールされたアクション」 また、AutoScaling の起動アクションは最大で 2 分間遅 延することがあります。 このため、遅延時間とインスタンスの起動時刻を考慮した 起動時刻を設定するようにしましょう。 タブで「予定アクションの作成」をクリックし、スケールさ AutoScaling による時刻起動 023 Appendix-C : Cloud ならではの大規模 CPU の利用 Appendix-A OpsWorks による時刻起動 OpsWorks による EC2 インスタンスのスケールアウトも 可能です。 OpsWorks での時刻起動も AutoScaling での時刻起動と 同じく、インスタンスの起動時間を見込んで時刻設定を行う 必要があります。 Appendix-B OpsWorks の Management Console で「Time-based また、OpsWorks がインスタンスの起動または停止する Instances」ページで時刻ベースによるインスタンスの追加 かのポーリングをバックグラウンドで行っており、ポーリン 設定を行います。 グ間隔が数分間隔となるため、起動させたい時刻が 10 時で OpsWorks では毎日もしくは特定の曜日の何時から何時 Appendix-C まで起動するかを設定することができます。 ある場合、起動時刻は 9 時としておくほうが 10 時を過ぎて 起動する可能性を考えると安全です。 曜日ごとに起動時刻を変えて起動させることも可能です。 OpsWorks による時刻起動 サーバーレスアーキテクチャーの採用 事前に予期できない負荷の急増など、EC2 インスタンス スマートフォンアプリはもちろんのこと、通常の Web サ のスケール速度が許容できない場合、AWS ならサーバーを イトでも近年の JavaScript フレームワーク、例えば React. 使わないという選択肢もあります。具体的には画像などの js を用いれば違和感なく実装できるかと思います。 静的なコンテンツは S3 から配信し、ユーザーごとに異なる または各種 SDK と Cognito を組み合わせることで、ユー コンテンツは API Gateway を通じて Lambda に処理させ ザーごとの処理をユーザー自身の端末に任せてしまうこと るといった方法です。 も AWS なら簡単に実装でき効果的です。 024 C-1 キャンペーン・セール特設サイト向きな事前スケールアウト CloudFront による可用性の向上 AWS で急激な負荷に対応する方法は、EC2 のタイムベー AWS WAF でのアクセス制御 スのスケーリングやサーバーレスなアーキテクチャ ーの ログインなどを伴う新規登録キャンペーンや一時的な特 採用だけではありません。それらと併用でき、さらにサー 設サイトにおいては、善良でないユーザーからのアクセスを ビスの可 用 性を高めることのできるサービスが Amazon 受けることもしばしばあります。悪意ある攻撃にもさまざ CloudFront です。 まな種類がありますが、急激に負荷が上昇する類のものも、 データベースへアクセスしようとする類のものも、AWS の サービスを組み合わせるとそれらを緩和することができま キャッシュによるオリジンの負荷軽減 CloudFrontは、高性能なコンテンツ配信サービスです。 す。CloudFront はもとより分散サービス妨害攻撃（DDoS） 対策が施されていますが、AWS WAF を組み合わせれば、あ 世界中のサーバーが近隣のユーザーからのリクエストを る程度の脆弱性攻撃も防げますし、CloudFront のアクセ 受け付け、E C2 や S3、または L a m b d a といったオリジン スログに Lambda と WAF などを組み合わせることで一時 へのアクセスを極力軽減し、ユーザーへ高速にデータを届 的に特定の悪意ある IP アドレスをブロックするといったこ けます。通 常キャ ッシュしにくいといわれるユーザーご ともできます。 とのコンテンツも扱いやすいよう設計されています。数秒 でも再利用可能なコンテンツがあればかんたんにキャッ シュ設定を追加でき、急激なアクセスにも耐えられるサイ トを構築できます。 025 Appendix-C : Cloud ならではの大規模 CPU の利用 Appendix-A C-2 オンプレで処理しきれなくなったバッチを AWS にオフロードして処理を実行 Appendix-B TEXT: 金春利幸 Appendix-C システムにバッチ処理はつきものです。データクレンジングや集計処理など様々な処理がバッチ処理として 行われます。最初からAWSでの稼働を前提に設計されたシステムであればLambdaやEMRなどを用いてバッ チ処理をスケーラブルかつ高速に処理することも可能ですが、オンプレで稼働させる場合、データ量に合わ せてスケーリングすることは困難です。 全面的に AWS に移行することが難しいという場合でも AWS は便利に使えます。 オンプレでは処理することが難しいバッチ処理を AWS にオフロードすることができます。 捌ききれなくなったデータを AWS で処理 データセンターと AWS を DirectConnect を用いた専用 線接続あるいは VPC への VPN 接続しオンプレミスの DB の 立ち上げ、バッチ処理を実施します。このとき、結果の書き 込み先はオンプレの DB になるようにします。 レプリケーションを RDS で取得するようにします。 （RDS は こうすることで計算量の必要なバッチ処理のみを AWS に オンプレや EC2 で稼働しているデータベースのスレーブに オフロードし、捌ききれなくなった計算を必要な時間内で処 なることもできます） 理することができるようになります。 そして、必要な計算量が得られるだけ EC2 インスタンスを AWS らしい方法ならどうなる？ AWS の利用を前提としたときのバッチ処理の方法として 動機能を用いて必要なタイミングで処理を起動して処理 はどういう方法があるでしょうか？ いくつか考えられる方 します。この場合 1 処理が 5 分以内に終わるように注意 法を挙げておきます。 する必要はありますが、EC2 インスタンスを用意する必 要がないため、かなり簡単に処理を実装することができ • バッチ処理専用の EC2 をバッチ処理実行時のみ起動し て処理する：必要な時間のみ高性能なインスタンスを起 チェインして処理することを検討する必要があります 動し短時間で処理を終わらせ、終了したらインスタンス • バッチ処理という考え方を変える：逐次処理可能な場合、 を停止あるいは削除します。こうすることでコストを抑え 処理可能になるごとに SQS に計算を指示するキューを追加 ながら短時間で処理を実行することができます。この方 し、キューに指示が入れば処理を行います。このとき EC2 法の場合、処理する時間は夜間に限る必要はありません を使うことも Lambda を使うこともできます。オンプレミス （DB にかかる負荷にもよるため夜間が適している場合 の場合は計算リソースの都合から夜間バッチを前提として もあります）。 • AWS Lambda を利用する：Lambda のスケジュール起 026 ます。5 分を超える処理を行う場合は、Lambda 関数を 考えていた処理であっても AWS を前提に考える場合は、 夜間バッチを前提として考える必要もありません。
© Copyright 2024 Paperzz
