2015年10月23日にアイティメディア主催**「主導権はユーザー側が持つ　企業のためのAWS徹底活用セミナー」**に登壇いたしました。

当日セミナーにお越しいただけなかった方にもお伝えできるよう本ブログにてコンテンツとしてお届けいたします。

セミナー概要

AWSの利用を躊躇されている方々へ

株式会社ISAO infra R&D プロジェクトリーダー 片貝 力也

本日はAWSの利用を躊躇している方々に向けて、利用当初の注意点や問題になりやすい事項を簡単に紹介させて頂きます。具体的な実例をもとにご説明させて頂きたいと思いますが、既に利用いただいている方々にとっては物足りない内容になってしまいます。その点、予めご了承ください。また最近ニーズが高まっているAWSでのセキュリティ対策についてもご紹介いたします。

EC2以外のサービスを利用しますか？

AWS（Amazon Web Searvices）を利用される予定の方々に質問です。 EC2以外のサービスを利用しますか？

もちろんEBSやELB、S3なども利用しないとサービスとして成り立たないかと思いますが、現状AWSにて構築を検討する際に、まずAWSで提供しているマネージド込みのサービスをどこまで使用するかが一つの重要なポイントになります。EC2上に自前でミドルウェア環境を構築していくのか、RDSやElastiCashなどミドルウェアまで揃えているマネージドサービスを利用するのか、どこまで利用するのか一度検討ください。ただマネージドサービスを利用することで構築の手間が大幅に省けますし、運用の手間も簡略化されるため、工数が減りコスト減にも繋がりますので、利用される事を通常お勧めします。

しかし、1点気を付けなければならないのがベンダーロックイン（※）状態です。 数年毎に別のシステムへの移設を検討しなければならない場合は、マネージドサービスを利用していると移設検討が非常に困難となってしまいます。ただAWS環境から他環境への移設メリットは無い、もしくは薄いケースが殆どだと思いますので、現状ですとマネージドのサービスを躊躇せずに利用して問題ないと思います。またAWS環境にて安定的なサービス運用をする為にもマネージドのサービスを利用する事は近道となります。

（※）ベンダーロックイン 特定の環境・技術に固定され、他との互換性が損なわれるとこと

ただシステム環境以外にも構築運用メンバーの技術スキルもAWSに踏襲・専属化していってしまいますので、昨今のインフラメンバーでは、オンプレミス環境のネットワーク設計や導入作業が出来ないといった事態も発生してます。

インフラエンジニアを抱えていらっしゃる企業様は、運用リソースの配置や今後のスキルパスまで考えていくことが必要です。

AWSの月額費用って本当に安いの？

AWS利用で発生する月額費用は、規模がある程度大きくなると決して安くは見えません。

特にオンプレミスで構築した場合のCPUのコア数やハードウェアのパフォーマンス等を、そのまま踏襲してAWSで試算をすると、1年や複数年のスパンでハウジング費用と比較すると高くなるケースが多々あります。ただし、これは単純に発生する月額費用を比較した場合の話なので、実際は見えにくい運用でのコストを加えて比較すべき内容です。

AWSは構築運用だけでなく、設計や管理、オンサイト作業のコストを除外できることも大きなメリットとなります。 例えばデーターセンターに行く必要がないというのが分かりやすい一例です。それらを計算に入れると正しいAWS費用の試算ができます。 またインスタンスの稼働を100%ではなく、実負荷を想定した変動性でコスト試算できるとよりメリットが見やすくなります。

リザーブドインスタンスって？

さらに、AWSにはリザーブドインスタンス（RI）という年間契約でお安くなるプランもございます。 このRIは1年もしくは3年契約での割引サービスだけでなく、「リザーブド」の名前が示すようにインスタンスの起動が約束されます。 契約しているとインスタンスの数が確保でき、稀にある「リソースが枯渇していて必要なインスタンスの数が上がらない」といった心配も無くなります。

インスタンスの起動に失敗した場合、数分〜数十分待ってから起動させる必要があるのですが、RIは契約分のリソースが確保される事になります。 手動でオペレーションしている場合は大きな問題にはなりませんが、規模が大きくなり自動化等を取り入れていると、スムーズなインスタンスの起動は重要な課題となります。

AWSのメンテナンスってどうなの？

EC2のメンテナンスには主に2種類あります。

• アップデート用メンテナンス
• リタイアメント用メンテナンス

1つ目はAWSが実施するセキュリティアップデートです。こちらは特定のタイミングを指定し、AWS側が実施するメンテナンスとなります。なので環境や対象によっては、そのタイミングでサービスを停止、メンテナンスに切り替える必要があります。ただライブマイグレーション等で対応できる範囲も増えているようなので、今後は年に1回あるかどうかだと考えてます。

2つ目はハードウェア故障やリタイアメントによる、インスタンスのstop/startとなります。こちらは取り扱いインスタンス台数が増えるにつて対象となる可能性も高まりますので、わたくしの感覚ですと1,000台程度起動していると毎週どこかで発生する程度の頻度となります。ただこちらは指定された日までの好きなタイミングでstop/startをすれば良いだけなので、通常サービスへのインパクトはそれほど高くなりません。※ただ通常平日の4:00からとかに実施しますので、作業者が頻度によっては少々大変になります。

またインフォメーションは英文メールでとどきますので、見逃さないように注意が必要です。 Eventとしてもマネージドコンソールで確認できますので、弊社はAPI経由でEvent監視をしてアラート発報させてます。

上限緩和申請って知っていますか？

意外に知られていないのですが、AWSには非常に多くの起動数や設定数の上限設定がなされています。 EC2インスタンスの起動数やEBSのトータルボリューム数、ELBの数、SecurityGroupの数等、それは多岐にわたります。 例えば、EC2インスタンスはタイプにもよりますが、20がデフォルトの起動上限数です。

よって、21以上のインスタンスを起動したい場合は、事前にマネージメントコンソールから上限緩和申請をする必要があります。 この上限緩和は少し時間を要しますので、構築作業の前日までには申請をしておいた方が無難です。

上限を50や100へは変更する事は容易だと思いますが、1,000とかには利用実績を伴わないと認められないと思いますので、あまり過剰な上限を申請する事はおすすめしません。再申請等で余計な時間が取られないように、適切な上限数を申請ください。

また色々と上限緩和を実施した後は、API経由で現状の各上限値を確認することが可能です。

監視はCloud Watchだけで十分ですか？

AWS側で用意されている監視サービス(CloudWatch)では、インスタンスのリソース面はモニタリングできますが、プロセスやサービスを監視することができません。 しっかりとした運用を実施するためには、自前の監視システム構築は必須となります。 ただEC2には監視エージェントを導入できますが、RDSやElastiCashには監視エージェントを導入できません。 この場合はCloudWatchから取得した値を、自前の監視システムで見るような連携が必要となります。

弊社の場合はZabbixとCloudWatchを利用して監視システムを構築しております。 また規模が大きな環境等ではZabbixへの監視登録を自動化する運用を実施してます。

AWSのセキュリティは不安ですか？

AWS環境を利用する際にセキュリティは大丈夫なのか、という心配をよく聞きます。

パブリックな共有環境となりますのでイメージ的に心配されるお気持ちも分かりますが、他アカウントへ自社のデータが共有されてしまう事などは発生しません。 しっかりとPCIDSS等の第三者認証もクリアしておりますので、オンプレミス環境で全てを自社責任で構築するよりもセキュリティ的には向上しやすいと思います。

しかし、セキュリティグループやOS・ミドルウェアの設定については、利用者側の責任で実施する必要があります。 ただこれはどの環境においても同じことだとですので、やはりAWSを利用した方が高いセキュリティを確保できると考えます。

WAF等の製品も仮想化が進んでいるので、AWSのマーケットプレイスから追加することが可能になりました。時間課金もできるので気軽に導入が可能です。

弊社はバラクーダ社とパートナー契約しておりますため、ご興味がある方は是非お問い合わせください。

「くらまね」のご紹介

弊社ISAOのクラウドマネージドサービスくらまねはお客様からのニーズでオンプレミスからクラウドへの移設、またはクラウドの新規構築も手がけております。

構築・設計・運用から24時間365日の障害対応まで一気通貫でお受けしております。 導入事例はこちら

強みとしては、構築からおこなっているために障害が発生した際にスムーズな復旧対応に定評いただいており、 さらに業界最安値級でのご提供をしております。

是非、下記バナーよりお気軽にご相談ください。