More Related Content Similar to 【公開版】AWS基礎 for 新卒エンジニア (20) 【公開版】AWS基礎 for 新卒エンジニア2. 講師紹介
● OGATA Tetsuji (@xtetsuji)
● Gaiax > RND > インフラチーム
● 1社目約10年、2社目約10ヶ月、3社目
ガイアックス2年10ヶ月(Now!)
● 学生時代の専門は数学(解析学)
● Perl、メールサーバ、ITプログラミング
教育が主な注力分野
● 趣味はクラシック音楽を聴いたり路線
バスに乗ったりすること
8. ECサイト Amazon.com のトラフィック
● 11月の小売のお祭り「ブラックフライデー」のトラフィックに耐えられるキャパシティー
のオンプレサーバを用意していた
● しかし、年全体で76%のリソースが余剰
● これが AWS につながった(らしい)
22. IaaS、PaaS、SaaS
● クラウドサービスを使うユーザの責任範囲や管理の程度に基づいたカテゴリ
● IaaS
○ Infrastructure as a Service ハードウェアの抽象化
● PaaS
○ Platform as a Service ソフトウェアが動くプログラミング基盤の抽象化
● SaaS
○ Software as a Service ソフトウェアを抽象化してサービスそのものを提供する
● AWSはすべてのサービスを提供している
○ EC2 が目立つので IaaSの存在感が大きいけれど
● IaaS は HaaS とも呼ばれ、SaaS は古い時代には ASP と呼ばれた
26. マネージド型とアンマネージド型の違い
● AWSが稼働を保証してくれるか
○ マネージド型は稼働を保証してくれる
○ アンマネージド型は稼働を保証してくれないので、ユーザが工夫して稼働を保証する必要がある
● 例:EC2はアンマネージド型なので、マネージド型のELBを使って複数のEC2インス
タンスを稼働させて冗長構成を組む
● 稼働を保証してくれるということは、高いSLAが定義されること、AWS側の過失で障
害が発生した場合に返金(実際にはCPUクレジットで)されること
● EC2はアンマネージド型なことは要注意
○ データセンターのサーバをEC2インスタンスにマッピングするだけでは、AWSのマネージドサービス
としての旨味を享受できない
● AWSのデザインパターンでは、マネージド型サービスを組み合わせて、疎結合・マ
イクロサービス的な設計が推奨されている
● そうはいってもうまくいかない場合はEC2で頑張ろう
30. EC2 のインスタンスタイプ
● t2.micro
○ t = 種類を表す
○ 2 = 世代を表す
○ micro = CPU スペックを表す
● 種類は t、m、c、r あたりを抑えておくとよい
○ t = テスト用?バースト型
○ m = ミドル?バランス型
○ c = CPU?計算型
○ r = RAM?メモリ型
● t は安いが、CPUクレジットを使い切ると一気に遅くなることに注意
○ それまではCPUクレジットを使ってベースライン以上にCPUを動かす(バーストする)ことができる
○ CPUクレジットとバーストの仕組みを知らないと、テスト時は普通に動いていたのに本番時に突然動
かなくなるということになる
31. EC2 料金オプション
● オンデマンド、リザーブド、スポットの3種類のインスタンスがある
● 通常使うのはオンデマンドインスタンス
○ いつでも作成できていつでも制限なく破棄できる
● 1年もしくは3年契約のリザーブドインスタンス
○ 一括払いでオンデマンドインスタンスより安くなる
○ 3年契約であれば2年弱で元が取れる(はず)
○ 実際は特定のインスタンスタイプを使う権利を買う
○ 一気に支払いが発生するので会社として買いづらい場合も
● AWS上での余剰をとても安く買うスポットインスタンス
○ オークション的
○ 入札をしてAWSで余っている安いインスタンスを買う
○ 他者によるより高い入札があれば、自分が使用中でもサーバが破棄される場合がある
○ バッチ処理や分散コンピューティングなどに使える
34. ELB とは
● ELB とは Elastic Load Balancer の略
● ロードバランサーとはネットワーク機器で、自分にぶら下がった複数のサーバに均
等にアクセスを分散させるもの
○ 例えばウェブアクセスをロードバランスする場合、ウェブサーバが複数台ぶら下がった状態で、その
うち1台が停止した場合、ロードバランサーは該当ウェブサーバをアクセス分散先からはずす
○ 冗長構成を組むことができる(1台気絶しても大丈夫)
○ ロードバランサーは、そのサーバが停止したかどうかを監視している。それをヘルスチェックと言っ
たりする
○ 我々のいるウェブ系業界ではロードバランサーの活躍場面は99.99%ウェブサーバの冗長化だが、
ウェブサーバ以外の冗長化も同じ原理で可能
■ xtetsuji が最初に10年いた会社はWebメールを開発している会社だったので、十数台規模の
SMTPサーバがデータセンター内のロードバランサの下にぶらさがっていた
36. ELB の種類
● ELB
○ CLB = Classic Load Balancer (これを指してELBとも)
○ ALB = Application Load Balancer
○ NLB = Network Load Balancer
● ELB 自体のバージョンアップで、元々の ELB の機能は CLB と呼ばれるようになっ
た
● 新しい ELB には HTTP 特化の ALB と、一般ネットワークロードバランシングを行う
NLB に分かれた
37. ELB の役割
● 負荷分散
● 疎結合性の向上
● SSLアクセラレータ
○ HTTPS暗号通信を行うが、復号化はELBで行い、末端のEC2インスタンスのウェブサーバには平文
にしたものを流す
○ EC2インスタンスの負荷が軽くなる
39. RDS
● RDS は Relational Database Service の略。AWS によるデータベース(RDBMS)の
フルマネージド型サービス
● サポートするRDBMSは以下
○ Amazon Aurora (MySQL互換)
○ MySQL
○ MariaDB (MySQL互換)
○ Oracle
○ Microsoft SQL Server
○ PostgreSQL
● マルチAZ構成にすることでミッションクリティカルな業務に耐える
● データベースサーバのバージョンアップもAWSが行ってくれる
● RDBMSが稼働しているサーバへのSSH等のログイン権限はない
41. RDSが適用されない場面
● コスト要件
○ EC2インスタンスのウェブサーバと同じサーバで動作するMySQLより、別途RDSインスタンスを立て
るRDSのほうがコストがかかる
● 無停止要件
○ RDSはAWSが勝手にバージョンアップをかける。停止時間を予告されるし、希望時間帯を設定する
ことができるが、24時間365日絶対に止められない場合はRDSを選びづらい
● 細かい設定が必要
○ RDSの設定項目はAWSコンソール(ウェブ管理画面)から設定できる厳選されたもののみ
○ MySQLの細かい設定を my.cnf に書きたいとか、独自コンパイルオプションを有効にしたいという場
合にはRDSは選びづらい
● 超高速な読み書き性能が要求される
○ RDSのIOPS(Input/Output Per Second) は 40000IOSPあたりが頭打ちとされる
○ それ以上の読み書き性能が必要な場合は、強力なEC2インスタンスの上に独自RDBMSシステムを
立てるか、RDBMS以外の選択肢を考える(KVSに代表されるNoSQLが代表的)
43. コラム:ユーザ数のオーダー
● ユーザ数のオーダーによって適用される技術が変わってくるという仮説
○ 〜1,000:比較的なんでも良い
○ 1,000〜1,000,000:LL言語とRDBMS
○ 1,000,000〜1,000,000,000:JVM言語とRDBMSとNoSQLの組み合わせ
○ 1,000,000,000〜:独自言語、独自実行環境、独自データベースを開発する?
○ ユーザ数で言うと、Facebookのユーザが20億、Instagramが8億、Twitterの会員数が3億くらいと言
われる
● 100万人以上のサービスを運営しないのであれば、LL言語とRDBMSをまずしっかり
勉強する
45. S3 とは
● S3 とは AWS が提供するマネージド型クラウドストレージ
● オブジェクトストレージと呼ばれるもの
○ オブジェクトストレージとは別にあるものはブロックストレージと呼ばれる
● S3 でファイルを保存する大きな区画のことをバケットと言う
○ バケットにキーを付けてファイル内容を保存する
● 具体的にはHTTPの転送手段を使ってファイルのCRUDを行う
● 耐久性は 99.999999999%、可用性は99.99%
○ 耐久性は9が11個続くことからイレブンナインとも呼ばれる
● ファイルを保存すると、特定のリージョンの3箇所に保存される(AZは最低2箇所は
使われるらしい)
● ファイルの更新や削除には結果整合性が適用される
● オブジェクトストレージとブロックストレージの違いは?
46. オブジェクトストレージとブロックストレージ
● 最大の違いは、ファイルシステムを意識するか
○ ブロックストレージはマウント前に フォーマットと呼ばれる作業を経てディスクフォーマットを行う必要
がある
○ ブロックストレージは、NTFSやext4といったファイルシステムが必ず前段にあり、使用者が準備する
必要がある
○ オブジェクトストレージは、ファイルシステムを意識しなくてもよい
● HDDにはディスク区画のどこに磁気情報を書くかという考慮が必要になり、ファイル
システムはパフォーマンスを考慮して最小ファイルサイズが何KBか考える必要が
ある
○ この最小区画のことを「ブロック」と考えるとブロックストレージをイメージしやすい
● オブジェクトストレージは、様々なものを抽象化しているが、それゆえパフォーマン
スはブロックストレージより概して悪い(そもそもHTTPだし)
47. S3 の仲間たち
● S3
● 低頻度アクセス(IA) S3
● Glacier
● 下に行くごとに保存費用は安くなるが、取り出しコストが跳ね上がることに注意
48. S3 と他のストレージ
● EBS
○ EC2インスタンスと一緒に使われ、HDDやSSDの仮想化
○ こちらはAWSで使われる代表的なブロックストレージ
● RDSなどのDB
○ こちらもストレージとみなすことができる
49. S3 は様々な AWS サービスの根底を支える
● ブロックストレージの EBS は、それ自身のスナップショット(バックアップ)のために
S3を使う
○ EC2 インスタンスのスナップショットイメージ、AMI も同様
● RDS も、任意の時点のスナップショットをS3に取ることができる
○ DBバックアップは重要
● インスタンス監視サービス CloudWatch など、監視や課金などの各種 AWS サービ
スのログ保存場所として S3 が使われる
● AWSのデザパタを無視して、オンプレから一対一でEC2インスタンスにしたとしても、
イレブンナインのS3でスナップショットが取れるだけでAWS化したメリットがあるとい
える
50. 補足:S3をディスクにマウントする方法
● S3 をディスクにマウントして、通常のファイル操作をすることによってS3上のファイ
ルを読み書きする方法はある
○ Goofys などのサードパーティツール
● AWS の EFS は東京リージョンにない(2018年5月現在)
○ 【追記】 2018年7月東京リージョンにてEFSリリース
● Goofys などのサードパーティツールは当然 AWS のサポート対象外
● そもそも、S3 を安易にマウントしようとすることに危険がないか考える
○ 簡潔に EBS が適切ではないか考える
○ 自分で EC2 インスタンスに NFS サーバを立てることも考える(EFSリリース以前)
○ ディスクを読み書きするツールが、それが低コストだと想定してS3にとって不利な読み書きをしまく
るということがないと保証できるか
● aws-cli の aws s3 sync などで代用できるのであればそうする
● 私は S3 をサードパーティツールでマウントすることに反対する立場
○ FUSE のパフォーマンスを調べてみる、またはファイル追記などの一部分の書き換えができないと
いったオブジェクトストレージ自体の制限を考えて、ファイルシステムとしてマウントした場合のトラブ
ルの数々を考えてみよう
61. Perl入学式とJPA
● JPA = Japan Perl Association http://japan.perlassociation.org/
○ ガイアックスは JPA の会員
● Perl入学式 http://perl-entrance.org/
○ ノンプログラマーを対象としたPerlの勉強会
○ 2012年より
● Perlに残った人達は親切
○ 他の流行りの言語よりも仲間は貴重なので…
○ 枯れた言語にも良いところがある
● JPA のガイアックス側メンバー、Perl入学式とも、スタッフ募集中!
62. Gaiax Technical Meetups
● https://gaiax.connpass.com/
● 毎月1回、社外向けにエンジニアイベントを行っている
○ 社内勉強会とは別
● 中期目標はガイアックスのイメージアップ、長期目標は就職活動の際に自社を選ん
でもらうこと
● 5月10日は #GAS活 #2
63. 数学勉強会 in 永田町
● Slack #topic-math / Facebook クローズドグループ
● 木曜日の19時から空いている場所で行う
● 2018年は「統計学のための数学30講」を毎週1講ずつ行う
○ ゴールデンウィーク前に微分積分の部分が完了
○ 5月10日からは線形代数編がスタート(最初はやさしいから入りやすい)
● 講師は毎週できそうな人の立候補で持ち回り
○ 予習をしてきて講義をする
● 講義は iPad Pro + Apple Pencil + VGA プロジェクターの電子書画で、毎回の講師
筆記データが残っている
64. インフラ&プログラミング勉強会
● xtetsuji 講師
● プログラミング作業がメインではないインフラチームにプログラミングなどを独創的
に教える
○ 原理主義者が聞いたら怒り出しそうなことも時々織り交ぜていますが、外部公開していないし良い
かなというテイスト
○ ガチプログラミングではないけれど、「こういう視点もあったのか」と驚くことはあるかも
● Qiita:Team に資料は公開
○ (社外非公開)
● インフラチーム以外も参加OK
○ 語りがメインコンテンツ(面白い)ときもある
○ ただ、インフラチームのコンテキストが強い(上記の対象とか、取り上げる話題とか)
● 開催は不定期(2週間に1度はやりたい)
68. 事例3:フィリピンから日本のツールにアクセスできな
い
● 日本(AWS東京リージョン or データセンター)に置いてある管理ツールに本社と子
会社がアクセスする
● ある日、フィリピン拠点からそれにアクセスできないと報告があった
● インフラチームで調査をした結果、フィリピン拠点から日本の当該サーバに至るま
でに経由する香港の海底ケーブルが損傷していることが原因だった
● フィリピン拠点から日本のツールに支障なくアクセスする方法はあるか
○ 全体的にコストはあまりかけられない
○ 香港の海底ケーブルは直しにいけない、また巨大ISP(AS)にのみ許されるインターネット上の経路
選択に関与することはできない