LoginSignup
1
2

More than 5 years have passed since last update.

@nkojima

AWSome Day for Partner 2018まとめ

Last updated at Posted at 2018-11-28

パートナー企業向けの無料イベント「AWSome Day for Partner」に参加してきたので、その時のメモをまとめてみました。
https://pages.awscloud.com/AWSomeDayforPartnerinTokyoNov.html

セッション1：AWSのグローバルインフラストラクチャとネットワークおよびコンピューティング

  • 講師：二條さん

AWSの歴史

  • 1995年にAmazon.com（オンライン書店）が設立した後、2006年にAmazon Web Service(AWS)のサービスが開始された。
  • AWSは、元々は社内の諸問題を解決するために作られたもの。
    • 世の中にはAmazonと同様の問題を抱えている企業が多い、つまりビジネスチャンスがあると捉えてAWSの提供を開始した。
  • Amazon.comの企業理念は「お客様第一」なので、AWSも顧客からの要望に沿って新機能を随時追加している。

AWSのメリット

  • 固定費を変動費に変えられる。
    • 機器の購入が不要となるため、固定資産税も不要になるはず...
  • 規模の経済の利点を享受できる。
    • AWSを導入した企業が何もしなくても、AWSが成長していくとスケールメリットによって料金が値下げされていく...
  • 需要予測が不要
    • 以前：需要予測に合わせて機器を購入する必要があった。
    • AWS：需要量に合わせてサーバーがスケールアウトする。
  • ビジネス環境の変化にシステムを追従させられる。
    • 必要な時に必要なものを揃えられる。
    • 逆に不要になった時に、すぐに停止（止める）ことができる。
  • データセンターの運用や保守にかかるコストが不要。
  • 即座にグローバル展開できる。
    • AWSが持つ世界中のデータセンターに対して、自由にデプロイできる。

リージョン、アベイラビリティゾーン

  • 18のリージョン、55のアベイラビリティゾーン、100+のエッジロケーションが存在する。
    • その内、中国の2リージョンと米国政府専用の1リージョンを除いて、15リージョンから自由に選択できる。
    • 中国は「金盾」があるので、中国国内に専用のリージョンを置いているものと思われる。
  • 1つのリージョンの中に、複数のアベイラビリティーゾーンがある。
    • アベイラビリティゾーンは互いに地理的に離れていて災害に耐えうる仕組みになっており、さらに互いに独立しているため、災害などで1つのアベイラビリティゾーンがダウンしても、他のアベイラビリティゾーンには波及しない。
    • 東京リージョンには4つのアベイラビリティゾーンがある。
  • アベイラビリティーゾーン間は高速なネットワークで結ばれている。
  • 複数のアベイラビリティゾーンを活用することで、災害に強いシステム（＝ベストプラクティス）になる。

VPC

  • AWS上で提供される、仮想的なプライベートネットワーク。
  • IPアドレスの範囲指定ができるため、オンプレミスと同様の構成にできる。
  • ルーティングの設定やセキュリティ設定もできる。
  • VPC内にEC2、RDS、Route53などのサービスを組み込むことができる。

コンピューティングサービス

  • EC2：柔軟な構成と制御ができる仮想サーバー。
    • 必要な時にプロビジョニング（起動）して利用できる。
    • サーバーインスタンスの取得と起動に要する時間は分単位。
    • 複数のアベイラビリティゾーンにまたがるようにしてEC2を起動すると、信頼性を向上させられる。
    • インスタンスタイプによってサーバーのスペックが決まるが、例えば「c3.8xlarge」の場合、「c」がインスタンスファミリー、「3」が世代、「8xlarge」がインスタンスサイズとなる。
      • 「t」と「m」がバランスの取れた汎用型。
        • 迷ったら「t」を選択して、あとはEC2インスタンスの挙動をモニタリングしながら、適切なインスタンスタイプに変えていけばよい。
      • 「c」がコンピューティング最適化型。
      • 「p」はGPU最適化型。
      • 「x」や「z」は大容量メモリ最適化。
      • 「d」や「i」「hi」「hs」がストレージ最適化型。
  • Lambda：サーバーレスなので管理が不要。
    • 私の勤務先でもLambdaを使っているケースはかなりあるが、処理時間の制限がネックになって導入を見送ったケースもあるらしい...
  • Lightsail：仮想プライベートサーバーで、単純なWebサーバーとアプリケーションサーバーを管理できる。
  • ECS：Docker環境を構築するためのサービス。

AMI

  • OSやミドルウェア、アプリケーションなどから成るテンプレート。
  • 最初は「素のOSのAMI」を使うか、AWS Marketplaceでサードパーティーのアプリケーションがインストール済みのAMIを使うことができる。
    • ユーザーが持っているISOイメージを使えるのかどうかは不明。

セキュリティグループ

  • デフォルトは「すべて遮断する」となっているので、用途に応じて随時設定する必要がある。
  • ウェブ層、アプリケーション層、データベース層でそれぞれ別のセキュリティグループにすることで、必要なポート以外を開放せずに済むため、よりセキュリティが堅固なシステムにできる。
    • 例えばウェブ層はpublic、データベース層はprivateにしておくと、よりセキュアな環境になる。

ELB

  • 通常はApplicationLoadBalancerか、NetworkLoadBalancerを使う。
    • レガシーなClassicLoadBalancerはあまり使われない。
  • ロードバランサーはヘルスチェックを絶えず実施しているので、死んだEC2インスタンスには処理を割り振らなくなる。
    • EC2インスタンスを別々のアベイラビリティゾーンで複数起動し、これらのEC2インスタンスに処理を割り振るためにロードバランサーを使うことで、高可用性構成を実現できる。
  • ロードバランサーにはSSLの証明書を登録できるので、EC2インスタンス側で個別にSSLの証明書の処理をせずに済む。

AWSの伸縮性

  • EC2、ELB、CloudWatch、AutoScalingグループを組み合わせることで、例えば「CPU使用率のしきい値を超えた」というメトリクスの受信をトリガーにして、自動的にスケールアウトさせることができる。
    • 必要なリソースを事前に見積もるのは難しいため、AWSの大きなメリットだといえる。

セッション2： ストレージとデータベース

  • 講師：吉田さん

EBS（Elastic Block Storage）

  • 低レイテンシーのブロックレベルのストレージで、OSなどが入っているブートデバイスのイメージ。
  • ブート/ルートボリュームだけでなく、EC2に対して複数のボリュームをアタッチすることも可能。
  • EBSのスナップショットを取得することで、データの損失を防げる。
  • GP2（general purpose）の汎用SSDが非常に一般的。
    • 汎用SSDは「最大IOPSが10000、最大スループットが160MiB/秒（20MB/秒）」となっている。
    • 一方で、市販のSSDは「最大IOPSが50000以上、最大スループットが500MB/秒」程度なので、物理サーバーよりもかなり低い性能に抑えられている（※帯域制限？）と思われる。
  • データウェアハウスなどシーケンシャルI/Oが多い場合はHDD、I/Oが非常に多い場合はプロビジョンドIOPS SSDを選択する。

S3（Simple Storage Service）

  • インターネット対応のストレージなので、HTTPでアクセス可能。
  • 1ファイルは5TBまでとなっているが、補完するデータの総量については上限がない。
  • オブジェクト（ファイル）をバケット（大きなフォルダ）に保存する。
  • S3バケットはリージョンごとに作られるが、バケット名は世界的にユニークにしないといけない。
    • バケット名が「S3のオブジェクトへのアクセスする際のURL」に使われるため。
  • S3上のデータは、少なくとも3つのリージョンにレプリケーションが保存される。
    • クロスリージョンレプリケーションと呼ばれている。
  • 一般的にはアプリケーションアセット（画像、動画など）や、バックアップ用、静的ウェブホスティング、ログ管理などに使われている。
  • 保管したファイルはデフォルトで非公開（プライベート）になっているので、契約書等を保管しても安心。
    • ただし、設定を間違えると全世界に公開してしまうことになる...

RDS

  • DBのサイズ変更が可能
  • バックアップやレプリケーションなどのDB管理が不要になるため、「本業」のアプリケーションの保守に注力できる。
  • 自動バックアップは「データを巻き戻したい」という時に使われる機能で、最大35日前まで遡れる。
    • おそらく、MySQLでいうところのバイナリログのようなものを使って巻き戻していると思われる。
    • 復旧を考慮すると、自動バックアップを有効にした方が良い。
  • 手動スナップショットは、「スナップショットから新しいDBインスタンスを作る」という時に使われる。
  • マルチAZを使うことで、高可用性の構成にすることができる。
    • リードレプリカを使うことで、リードの多い（リードヘビー）アプリケーションの場合は負荷を分散することができる。
    • RDSについてもCloudWatchで負荷などをモニタリングして、適切なインスタンスサイズにすることが肝要。
  • RDSでは「Aurora」という独自のRDBMSがある。
    • MySQL5.6/5.7とPostgreSQL9.6に互換性あり。
    • 64TBまでディスクがシームレスにスケールする。
    • 3つのアベイラビリティゾーンの6か所にデータが書き込まれるので、耐障害性が高い。
    • クエリ同時実行数やテーブルサイズが大きい場合に向いている。

DynamoDB

  • DynamoDBは、NoSQLの一種。
    • NoSQLは「Not Only SQL」、つまりデータの特性に合わせてRDB以外のDBを利用しようという標語。
  • データはKey-Value型で保管され、スケールアウトに対応することができるのが特徴。
    • Key-Value型のデータベースなので、比較的単純なデータを格納するのに向いている。
    • 主キーの代わりにパーティションキーというものがあり、このパーティションキーに従って複数のパーティションに保管することができる。
    • 従来のRDBはスケールアップするのが特徴だったので、ここが大きな違いとなっている。
  • その他に、保存できる容量に制限がない、リクエストキャパシティ（読み書きの回数）をプロビジョニングおよび変更できるといった特徴がある。
  • DynamoDBのデフォルトは「結果整合性のある読み込み」となっている。
    • 「結果整合性のある読み込み」は、最近の書き込み操作が反映されていない可能性があるが、少し時間が経ってからアクセスすると最新のデータが返される。
    • 「強い整合性のある読み込み」は、書き込み操作の内容が反映されてから読み込みを行うため、常に最新のデータを取得することができる。

Redshift

  • ペタバイト規模のデータウェアハウス。

ElastiCache

  • 高速なキャッシュサービス。

セッション3： AWSのセキュリティの基本

  • 講師：二條さん

AWSのセキュリティに対する考え方

  • セキュリティはAWSの最重要事項。
  • 「責任共有モデル」がベースとなる考え方。
    • AWS上で構築したシステムのセキュリティを保つために、「AWSが果たすべき部分」と「利用者が果たすべき部分」を分けている
    • お互いが責任をきちんと果たすことで、セキュリティを維持することができる。
    • オンプレだと一軒家だが、AWSのようなクラウドはマンションのようなものなので、「共有エリアはAWSがセキュリティを担保し、各自が持っている部屋については自身で管理する」というイメージになる。
      • EC2の場合、OS以上の領域は各自で責任を持って管理することになる。
      • S3のようなストレージの場合、データについては各自で責任を持って管理することになる。
    • 利用者が責任を果たすべき部分であっても、セキュリティグループのようにセキュリティを維持するための仕組みをAWSが提供していることもある。

ネットワークのセキュリティ

  • 組み込みのファイアウォールを使えるほか、DDos攻撃の緩和、通信の暗号化などを利用できる。

その他のセキュリティ

  • データの暗号化
    • キーマネジメントシステム
    • IAM（アクセスコントロール）
    • MFA（多要素認証）

AWS Service Catalog

  • 自社のコンプライアンスに沿った形でAWSを利用させる目的で、AWS Service Catalogを使うケースもある。

IAM(Identity and Access Management)

  • AWSリソースへのアクセス制御（認証、認可）
  • クラウドサービスへのアクセス（コンピューティング、ストレージ、DB、アプリケーションサービス）
  • ログイン情報となるIAMユーザーと、それをまとめるIAMグループに加えて、権限やロール（役割）を管理する仕組みもある。
  • アカウントルートユーザーが、すべてのAWSサービスへの完全なアクセス権を持つ。（※Linuxのスーパーユーザーと同じ）
    • アカウントルートユーザーでのログインは最初の1回とし、以降はIAMユーザーでログインすると、ルートユーザーのアクセスキーの漏洩を防止できる。
  • AWSのサービスへのアクセスを規定したものを「IAMポリシー」と呼び、この内容が書かれたJSONファイルを使うことになる。
    • IAMポリシーはIAMユーザーやIAMグループ、IAMロールに割り当てて利用する。
  • IAMロールを使うと、IAMロールに割り当てられた権限を一時的に使うことができるようになる。
  • EC2インスタンスにAWS認証情報を保存しておくと漏洩のリスクが高まるため、IAMロールを使って権限を一時的に与えるのが望ましい。
  • IAMはAWS上のサービス用の認証なので、OSやアプリケーション上の認証には使えない。

AWS STS（一時的セキュリティ認証情報）

  • アクセスキーID、シークレットアクセスキー、セッショントークンなどを作ることができる。
  • 認証情報の有効期間は15分～36時間ほど。

AWS Trusted Advisor

  • 利用状況を自動的に解析して、ベストプラクティスや推奨事項を教えてくれる。
  • コスト最適化やセキュリティ、耐障害性、パフォーマンスの4分野で推奨事項を教えてくれる。
    • 例えば、22番ポートが全世界に公開（0.0.0.0/0）されている場合などに警告してくれる。
  • AWSとのサポート契約がBasicやStandardではなく、BusinessやEnterpriseだとフル機能を活用できる。

セッション4： Well-Architected Frameworkと料金の話

  • 講師：吉田さん

Well-Architected 一般的な設計原則

  • 必要キャパシティの推測をやめる。
    • AWSの費用を見積もる際には、ある程度は必要キャパシティの推測が必要になるような気もする...
  • 本稼働スケールでシステムをテストする。
    • 「本稼働スケールでシステムをテスト『できる』」というのが正確かもしれない。
  • アーキテクチャの実験を容易にするために自動化を取り入れる。
  • 革新的なアーキテクチャを許容する。
    • 次々にリリースされる新機能・新サービスは顧客からの要望に基づくものなので、どんどん使ってシステムを改善してほしいという趣旨の話だった。
    • これを実現するには、新機能・新サービスのキャッチアップが大変そう...
  • データドリブンでのアーキテクチャ変更。
  • Game Day：本番で想定される事態を予めテストする。

Well-Architected Frameworkの5つの柱

  • 運用上の優秀性
    • システムのモニタリング、運用のコード化、頻繁に小さく可逆的な変更を行う
  • セキュリティ
    • アイデンティティとアクセスの管理、転送中と保存中のデータ保護、インシデントへの対応
  • 信頼性
    • 回復手順のテスト、水平方向へのスケール
  • パフォーマンス効率
    • 最新技術を積極的に導入、グローバル化への対応、試行の回数を増やす
  • コスト最適化
    • 需要と供給の一致、従量課金モデルの導入、所有コストの低減

料金の基礎

  • ベースは従量課金制。
  • 予約による値引き（リザーブドインスタンス）もある。
    • 予約による値引きは、「全額前払い」、「一部前払い」、「前払いなし」の3種類の支払い方法がある。
  • 使うほど単位当たりの支払いが値引きされる。
    • ボリュームディスカウント（S3を大量に使用すると、ディスク使用量やネットワーク転送量に応じて徐々に安くなる）
  • AWSの拡大に合わせてさらに値引き
  • 無料利用枠がある。
    • 12ヶ月無料だけでなく、無期限無料の利用枠もある。
  • 追加料金なしのサービスもある。
    • VPC、Beanstalk、IAMなど

料金に関する詳細情報

  • 一般的な利用では、EC2とRDS、ネットワーク転送量から大まかな利用料金が分かる。
    • 利用するサービスの大半はEC2とRDSなので、これに加えてネットワーク転送量を抑えておけば概算の料金が分かる。
  • EC2はインスタンスの起動している時間で課金されるが、秒単位での課金となる。
    • インスタンスの設定（リージョン、OS、コア数、メモリ量）で課金額が大きく変わる。
    • オンデマンド（随時購入）、リザーブド（予約購入）、スポット（指値購入）の3つの買い方がある。
  • ELBはトラフィックに応じて課金額が決まる。
  • CloudWatchは1分単位での詳細なモニタリングは、別途料金が必要になる。
  • S3はストレージ容量、リクエスト回数、データ転送量の3つで課金額が決まる。
    • S3はストレージクラスを「低頻度アクセス」に変えると課金額を低減できる。
  • RDSはインスタンスの稼働時間に加えて、エンジンの種類、インスタンスサイズ、メモリクラスによって課金額が決まる。
    • 購入方法はオンデマンドとリザーブドの2種類がある。
  • TCO計算ツール
    • オンプレミスの資産を入力すると、AWS上でどの程度の費用になるかを計算することができる。
  • 簡易見積もりツール
    • 主要なサービスの概算費用を計算できる。
    • これは何度か使ったことがあるので大丈夫そう。

その他

会場の様子

  • 会場は目黒駅南に位置する目黒セントラルスクエアの21F。
  • 3Fまでエスカレーターで上がってから、3Fのエレベーターホール前のゲートでスタッフの方に声をかけて、セミナールームまでのエレベーターに乗れるようにゲートを開けてもらう。（※駅の改札のようなゲートがある）
  • 21Fに着くと入口右手に受付があり、そこでスタッフの方に申込完了のメール（※印刷したもの）を渡すと、ビジター用の入館証を渡される。
  • セミナールームは3名掛けのテーブルが縦に6個、横に12個ほど並んでいる大きな部屋だった。
    • それでも座りきれない参加者が出ていて、テーブルの後ろに椅子を並べて座っていたので、おそらく200名以上は集まっていたと思われる。
  • セミナールームの入口にはパンフレットと水が用意されていて、自由に貰うことができる。

雑多な話

  • 遅刻者が凄く多かったので、開始が10分ほど遅れた。
  • ノートPCを持っていくとメモをするのに便利だが、会場内で充電できないため、満充電で持っていくのがベター。
    • 出来れば電源設定で"省電力"に設定しておかないと、長時間のセミナーの途中で電池が切れてしまうかもしれない。
    • Macbookでドヤってる人が多いかと思いきや、Mac率は意外に低かった。
      • Let'sNoteやVAIO、Fujitsu、iPad、Surfaceらしい端末も見られたが、ノートPCなどを持ってきていない人もちらほら居た。
  • 前の列にはスマホをずっといじっていたり、居眠りをしていたりと態度の悪い受講者が多くて驚いた。
  • セミナーではファイアウォールやルーティングなどの用語が当たり前のように出てくるので、多少は技術を知っている人でないと理解できないかもしれない。
  • AWSome Dayは「オーサムデイ」と読むらしい。
    • 「畏敬の念を抱かせる」「素晴らしい」といった意味を持つ"awesome"に引っかけていると思われる。
  • セッションの合間に「Ask The Speaker」コーナーが設けられて、講師の方に直接質問することができる。
1
2
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
2