2018/5/10に行われた「ガイアックス新卒エンジニア研修2018 AWS編」（社内教育・非公開イベント） で発表したトークのスライドです。

1. AWS基礎
for 新卒エンジニア
2018/05/09
OGATA Tetsuji (@xtetsuji)
2018/05/09 新卒エンジニア研修

2. 講師紹介
● OGATA Tetsuji (@xtetsuji)
● Gaiax > RND > インフラチーム
● 1社目約10年、2社目約10ヶ月、3社目
ガイアックス2年10ヶ月(Now!)
● 学生時代の専門は数学（解析学）
● Perl、メールサーバ、ITプログラミング
教育が主な注力分野
● 趣味はクラシック音楽を聴いたり路線
バスに乗ったりすること

3. 講義内容
● ガイアックスのオンプレとAWSの歩み（30分）
● AWSの概要と主要サービスの説明（30分）
● ハンズオン（60分）
○ 冗長構成
○ RDS
● ガイアックスでの事例紹介とクイズ、設計演習（60分）
人の話を聴くのは疲れる（しかも4月から毎日）ということで、脱力気味にお送りします

4. AWS を使ったことがありますか？
● 前に聞いたら、皆さん一度は使ったことはあるとのこと
● 初歩でも、触れているだけで大きい
● AWSには数限りないサービスがあるので、全部学ぶことは至難の業
● 使えるところだけまず無理せず使っていくことが大事

5. Gaiaxのサーバ構成（オンプレ・クラウド）
● 昔はオンプレのみ400台くらいあった？
● オンプレについてはデータセンター研修で見れます
● 今はオンプレを減らそうとして200台くらい？
● オンプレは色々大変なので減らそうとしている
● 様々なクラウド提供事業者がいるが、Gaiax では AWS 寄せしている
○ 一部 GCP や Azure を使っている事業部があるらしいがインフラチームで感知していない

6. オンプレからクラウドに移行するのはなぜ？
● 長期的なランニングコストはオンプレ＆データセンターの方が概して低い
● しかしオンプレは例えば以下の点で問題を抱える
○ 柔軟性がない
○ 入念な初期設計がソフトウェア以上に必要
○ 人件費、専門の知識を持ったエンジニアの稼働コストがかかってくる
○ 耐障害性を高くしようとすると桁違いのコストがかかる（冗長構成、ディザスタリカバリ）
○ ハードウェアの劣化や故障、また減価償却といった、経年劣化への対応が必要
○ サーバの少量購入ではバリューディスカウントが効きづらい

7. オンプレの懸念点：柔軟性がない
● 「急激なアクセス増があります！サーバ増強して下さい！」
○ 設計、ベンダー見積もり、稟議、経理申請、発注、納品、キッティング（開梱からOSが使用可能にな
るまで）、サーバソフトウェア等のインストールと設定
○ オンプレはあまりに時間がかかる
● 「結局鳴かず飛ばずでした！サービス縮小（終了）します！」
○ 買ったサーバはそのまま（余剰資源として活用できるかもしれないけれど）
○ 減価償却として毎月コストが乗っかってくる（収益が見込めないのに）
● ピーク時に合わせたサーバ増強をする必要がある
● サーバは急に買えない（重要なので二回）

8. ECサイト Amazon.com のトラフィック
● 11月の小売のお祭り「ブラックフライデー」のトラフィックに耐えられるキャパシティー
のオンプレサーバを用意していた
● しかし、年全体で76%のリソースが余剰
● これが AWS につながった（らしい）

9. 入念な初期設計がソフトウェア以上に必要
● 一度購入したサーバは替えがきかない
● CPUやメモリのサイズは入念な見積もりが必要
○ 「足りない」も深刻だけど、「余り過ぎた」方が情けないかも
● 追加購入は様々な障壁があり、余剰サーバを売る方法がほぼ無い

10. 人件費、専門の知識を持ったエンジニアの稼働コス
トがかかってくる
● とかくプログラミングスキルばかり取り沙汰されるオープン系IT業界ですが
● プログラミングを主業務としないオンプレインフラエンジニアも、専門知識がかなり
求められる
○ ベンダースイッチの設定知識
○ 複雑なネットワークの構築スキル
○ ハードウェアによる冗長構成の担保
○ インターネット回線の選定や契約、また冗長化
○ …などなど
● 専門知識を求められる割に、業務時間の結構な割合を現地作業（いわゆる「力仕
事」）に消費することも…
○ 移動時間ももったいない
○ ホワイトワーカーなのかブルーワーカーなのか
● もちろんクラウドでも、冗長構成やネットワークの設計スキルは必要だけど、

11. 耐障害性で桁違いのコスト
● 特にストレージとネットワークで「全体として機能を保ち続ける（壊れない）」ことを求
め続けると桁違いのコストになる
○ 一つの機器が1000万円以上することもザラ
○ ストレージだと NetApp EMC …、ロードバランサーだと F5 Networks (BIG-IP)
● 1000万円クラスの製品を買った後で「サービス鳴かず飛ばずだったのでやめます」
だと泣くに泣けない
● クラウド以前の時代に分散オブジェクトストレージを作った会社から悲痛な叫びが
● ELB と S3 は安い！

12. 経年劣化への対応
● 物理製品は日々劣化していく
● 特に物理駆動するものと電気信号が常時流れる部分はこわれやすい
○ 円盤が回るハードディスク
○ スイッチのLANポート
○ ハードディスクのRAIDコントローラ
● サーバの使用期限に応じて減価償却が設定されるけれど…
● 故障するサーバの対応する必要があり
● 処分にもコストがかかる

13. サーバの少量購入ではディスカウントが効きづらい
● 全体で100台〜1000台規模ではボリュームディスカウントの類が効きづらい
○ 全体がその量であれば、一度の購入は多くて10台〜100台規模のはずなので
● プライベートクラウドが流行ったものの、1000台規模だと「気軽に捨てる」という選択
肢が取りづらい
○ そもそも物理サーバの購入は、資産として購入している場合がほとんどで、だいたいは「それを捨て
るなんてとんでもない」ケースになる（減価償却している間は特に）
● AWSなどの巨大クラウドベンダーが間に入ることで規模の経済が生きる

14. オンプレをゼロにできるか？
考えてみよう

15. オンプレをゼロにできるか
● ガイアックスが現在もつ200台ほどの物理サーバをゼロにできるか？
○ たぶん頑張ってもラック2本くらいは残るのではないか
● クラウド移行を阻止する要因
○ クラウドに懸念を表明する社内部署や顧客の存在
■ 経理部門
■ 旧来のオンプレに信頼を寄せる企業
○ 金融系はだいぶクラウドアレルギーが減ってきた印象
● 拠点の機器はゼロにはできない
○ 完全に管理委託してしまうことはできるけれど
● データセンターのサーバを（直接または間接で）使っている人達には、様々な関係
者がいて、全員の説得は困難
● 今の時代、逆にオンプレの経験ができるのもいいでしょ？

16. オンプレをゼロにできたブルー会社
● オンプレサーバはほぼ自社コンテンツ
● もしくは強い親（親会社だったり主要な発注者だったり）がクラウドの号令を出した
● 関係者にクラウドアレルギーが無かった
上記のような好条件のものといえる場合も
重要なのは「弊社はオンプレをゼロにした」と自慢してくる同年代に惑わされないこと
ブルー＝青い芝

17. ガイアックスのデータセンター→クラウド
● サーバ1台をEC2インスタンス1台にうつしていくパターン
○ OSは余裕があれば新しいものを、そうでない場合は同様のものを
● 本来はAWSとクラウドに親和する形にしていくのが良い（後述）
○ 現状はAWSのデザインパターンには適合していない
○ AWS以後に生まれたサービスはこの限りではない
● インフラチームがプログラミングファーストなチームではなかったので、クラウドをソ
フトウェアとして活用する思想がまだ十分行き渡っていない
○ 急進的にやりすぎても、こういうのはうまくいかない
● 個人的(xtetsuji)に、非常に高い耐久性を持つS3に身を預けられるだけでもAWSを
使う価値がある

18. 今後のガイアックスインフラチームのAWS展望
● APN事業者であることを活かす
○ 新たな形態のAWSコンサルタント
○ AWSの資格を手広く取得していく
● オンプレの平行移動である現状を、AWSデザインパターンに則ったもの、もしくは
サーバレスの仕組みに置き換える
● AWSで最低限必要とされる冗長構成を啓蒙し、安価に導入できるようにする
● 各事業部が共通して必要としている（が、学びづらい）知識を先手を打って学ぶ
● 他のクラウド事業者を見てみたいが、中途半端になることも考慮する

19. AWSの概要と主要サー
ビスの説明

20. ● クラウドコンピューティングとは何か
● AWSとは何か
● アベイラビリティゾーン、リージョン、エッジロケーション
● アンマネージド型とマネージド型の比較

21. クラウドコンピューティングとは何か
● 従量課金制
● オンデマンド
● インフラストラクチャをハードウェアではなくソフトウェアとして扱う
● オンプレには無かった柔軟性を、ソフトウェアのように得られるもの

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 と呼ばれた

24. ● 多い
● 全てを使う必要は無く、必要なもののみをしっかり使えればいい
○ ただ、どんなサービスかくらいは知っているといいかも
● 今回の講義で最重要サービスは解説するので、それを集中的に活用して、事業の
中で特有の悩みが生じた時に新たなサービスを探せば良い

25. AWSのグローバルインフラストラクチャ
● 概念的には、AWSのデータセンター＜アベイラビリティゾーン（AZ）＜リージョン＜
エッジロケーション
● AWSと言えど、根底には特定の地域にハードウェアを置いていることには変わりな
いので、その特性を理解する必要がある
○ どのようなときにそれが必要？
● AWSにもデータセンターがあり、それらはアベイラビリティゾーンというくくりの中に1
棟もしくは数棟ある
● リージョン内のアベイラビリティゾーンは、互いに同時に危険を被らない程度に離れ
た場所にある
○ 危険とは、電源消失、洪水、火災などを言う
○ 「東京リージョン」であれば、区内に1つ、郊外に1つくらいの感覚か？
● リージョンは全世界に16個（2018年5月現在）ある。日本には東京、大阪
○ 大阪は特殊なリージョンなので通常は東京リージョンを使う
● エッジロケーションは、リージョンとは独立に世界中にあるAWSのコンテンツ配信拠
点
○ CloudFront や Route53 がここに属する

26. マネージド型とアンマネージド型の違い
● AWSが稼働を保証してくれるか
○ マネージド型は稼働を保証してくれる
○ アンマネージド型は稼働を保証してくれないので、ユーザが工夫して稼働を保証する必要がある
● 例：EC2はアンマネージド型なので、マネージド型のELBを使って複数のEC2インス
タンスを稼働させて冗長構成を組む
● 稼働を保証してくれるということは、高いSLAが定義されること、AWS側の過失で障
害が発生した場合に返金（実際にはCPUクレジットで）されること
● EC2はアンマネージド型なことは要注意
○ データセンターのサーバをEC2インスタンスにマッピングするだけでは、AWSのマネージドサービス
としての旨味を享受できない
● AWSのデザインパターンでは、マネージド型サービスを組み合わせて、疎結合・マ
イクロサービス的な設計が推奨されている
● そうはいってもうまくいかない場合はEC2で頑張ろう

27. 稼働保証とSLA
● 指定期間の間、どれくらい正常稼働を保証しているかの数値としてSLAというもの
がある
○ SLA = Service Level Agreement
● 正常の指標は様々であるが、純粋な稼働時間が多く採用される印象がある
● 年間でのSLAの例
○ 99.9% = 8時間くらいは停止を許容できる
○ 99.99% = 停止が許容できるのは52分まで

28. EC2

29. EC2とは
● 仮想コンピューティング環境
● いわゆるハードウェアサーバの仮想化
● 物理サーバと同じく、電源を入れたり消したり、ハードディスク(EBS)を付けたり外し
たり、ネットワークカード(ENI)を付けたり外したりできる
● CPU とメモリのサイズによってインスタンスタイプが分かれている
○ t2.small とか m4.large とか

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で余っている安いインスタンスを買う
○ 他者によるより高い入札があれば、自分が使用中でもサーバが破棄される場合がある
○ バッチ処理や分散コンピューティングなどに使える

32. EC2はアンマネージド型サービス
● EC2はアンマネージド型サービス（重要）
● 1台だけを稼働させた状態ではAWSはSLAすら定義してくれない
● AWSに稼働を保証してもらうためには、ELBを使って異なるAZにEC2インスタンスを
配置する必要がある
● 全てはコスト次第

33. ELB

34. ELB とは
● ELB とは Elastic Load Balancer の略
● ロードバランサーとはネットワーク機器で、自分にぶら下がった複数のサーバに均
等にアクセスを分散させるもの
○ 例えばウェブアクセスをロードバランスする場合、ウェブサーバが複数台ぶら下がった状態で、その
うち1台が停止した場合、ロードバランサーは該当ウェブサーバをアクセス分散先からはずす
○ 冗長構成を組むことができる（1台気絶しても大丈夫）
○ ロードバランサーは、そのサーバが停止したかどうかを監視している。それをヘルスチェックと言っ
たりする
○ 我々のいるウェブ系業界ではロードバランサーの活躍場面は99.99%ウェブサーバの冗長化だが、
ウェブサーバ以外の冗長化も同じ原理で可能
■ xtetsuji が最初に10年いた会社はWebメールを開発している会社だったので、十数台規模の
SMTPサーバがデータセンター内のロードバランサの下にぶらさがっていた

35. ELB の役割
● インスタンスの負荷分散
● 異常なインスタンスを検知したり切り離したりといった対応
● パブリック用、プライベート用、両方で使用可能
● HTTP、HTTPS、またTCPプロトコルで使用可能

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インスタンスの負荷が軽くなる

38. RDSと各種DB

39. RDS
● RDS は Relational Database Service の略。AWS によるデータベース（RDBMS）の
フルマネージド型サービス
● サポートするRDBMSは以下
○ Amazon Aurora (MySQL互換)
○ MySQL
○ MariaDB (MySQL互換)
○ Oracle
○ Microsoft SQL Server
○ PostgreSQL
● マルチAZ構成にすることでミッションクリティカルな業務に耐える
● データベースサーバのバージョンアップもAWSが行ってくれる
● RDBMSが稼働しているサーバへのSSH等のログイン権限はない

40. RDSが適用される場面、適用されない場面
● RDSは多くの場面で素晴らしいソリューション
● ただ、RDSが向かない場面もある
● 考えてみよう？

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が代表的）

42. …とRDSが適用できない場面を上げましたが、私見だと日本の世の中の大部分のサー
ビスを満たすと思います

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をまずしっかり
勉強する

44. S3

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 のパフォーマンスを調べてみる、またはファイル追記などの一部分の書き換えができないと
いったオブジェクトストレージ自体の制限を考えて、ファイルシステムとしてマウントした場合のトラブ
ルの数々を考えてみよう

51. ネットワークとセ
キュリティ

52. セキュリティグループとネットワークACL
● セキュリティグループ(SG)はポートやアクセス元ごとにアクセス可否を決定するもの
● セキュリティグループはEC2やRDS等のインスタンスやELBなどに適用する
○ EC2の場合、正確にはENIに適用するもの
● セキュリティグループは基本拒否、ステートフル
● ネットワークACL(NACL)はポートやアクセス元ごとにアクセス可否を決定するもの
● ネットワークACLはVPCに適用する
● ネットワークACLは基本許可ルールが最初に入っている、ステートレス

53. セキュリティグループとネットワークACLの使い分け
● セキュリティグループは大まかな役割ごとに作成したものを、各種インスタンスに付
与する
○ オフィス拠点からSSHできるSG
○ 80番と443番を受けることができるSG
● ネットワークACLはネットワーク全体で拒否したいものを入れる
○ 不正アクセスを行うIPアドレスを締め出し
● ガイアックスではセキュリティグループをメインで使用して、ネットワークACLは上記
のような補助的な使用をしている
○ VPCをあまり活用できていないという反省点もあるけれど…

54. ハンズオン

55. ELBを使って2台のEC2サーバを冗長構成にする

59. あとは実演で（資料作成する時間がなかった）

60. 宣伝

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度はやりたい）

65. クイズ、設計演習

66. 事例1：大量のファイルのバックアップ
● EC2インスタンスで提供しているサービスは、各種ファイルが大量にたまる
● あまりにもたまりすぎるので、保存期限を365日と定めたが、クレームが来た時に対
応できるように、もう365日は隠し領域に保存したい
● どのようなバックアップソリューションがいいか
○ ファイルの種類によって適切なソリューションはかわる？

67. 事例2：WordPressが過負荷に
● コスト的要求、また担当者のシステム過負荷に対する認識が少なく、EC2が1台の
みで運用されていたWordPressサーバが有事の際に過負荷となった
● アクセスが集中する有事の時こそ閲覧できるべき（情報公開の意味でも）
● あとIT企業なのにカッコ悪い
● 有事の際にWordPressが過負荷になりづらい構成はどうすればいいか
○ Wordpressは記事更新やテーマ・プラグインインストールの際にディスクに情報を書くことに留意す
る必要がある

68. 事例3：フィリピンから日本のツールにアクセスできな
い
● 日本（AWS東京リージョン or データセンター）に置いてある管理ツールに本社と子
会社がアクセスする
● ある日、フィリピン拠点からそれにアクセスできないと報告があった
● インフラチームで調査をした結果、フィリピン拠点から日本の当該サーバに至るま
でに経由する香港の海底ケーブルが損傷していることが原因だった
● フィリピン拠点から日本のツールに支障なくアクセスする方法はあるか
○ 全体的にコストはあまりかけられない
○ 香港の海底ケーブルは直しにいけない、また巨大ISP(AS)にのみ許されるインターネット上の経路
選択に関与することはできない