社内勉強会「AWS×SRE勉強会」参加レポート #前編

2019/06/01

2019年5月16日、17日に弊社で「AWS×SRE勉強会」というAWSの方々と弊社SREメンバーを迎えたクローズドイベントがありました。
このエントリはそのイベントの参加レポートです。

概要
Day1 - AWSxSRE勉強会

概要

この勉強会はDMM.com 南町事業所の9Fフリースペースにて、開発者が**「AWSやDocker、Datedog等を活用したクラウドアーキテクチャを学び、プロダクションで活用できる知識を学習する」**事を目的として、 2日間に渡って開催されました。

Day1 - AWSxSRE勉強会

1日目は、DMM型のSREが目指す未来への共有と、AWSのフルマネージドサービスに関する座学。Dockerのハンズオン学習がありました。

#1.「DMM型 SRE」とは

登壇者 : SREチーム大木裕介さん（@_y_ohgi ）/ 合同会社 DMM.com
概要 : イベントの開始前に「DMM型のSREとは」どういった考えなのか？についての基調講演的なものがありました。

このセッションでは、様々なサイトリライアビリティエンジニアリング（以後SRE）の考え方が存在している昨今において、弊社の「SRE」が考えている事は、「プロダクトにおけるAgilityを最大化するチーム」で「プロダクトの本質に集中できる環境を提供する」が目的であるということの共有がありました。

この目的を実現していくため「AWS」「Terraform」「Docker」「Datedog」というフレームワークを適切に活用していく。

AWSのマネージドサービスをフル活用！
- 基本軸としてAWSを利用するが、他クラウドサービスが利用不可というわけではない
Infrastructure as Codeでの自動化！
Dockerのコンテナ活用でDevからPrdまでを効率化！
Datadogの活用でデータドリブンな意思決定！

これらを整えていくことで、開発者がプロダクト以外のことに時間を取られない状況を作り、結果的にプロダクトの事だけ考えられるようにしていくとの事。

これはみんながハッピーになるので積極的に取り入れていきたいですね。ちなみに、SREについて詳しく知りたい場合はGoogleのSRE本がオススメとのことでした。

#2. 「Amazon Web Service」との関わり方について

登壇者 : Ishida Katsuhiko さん / AWS Japan SA
概要 : これからAWSを利用するにあたって開発者はどのように考ればよいか、AWSのカルチャーがどのようなものか、サービスの学び方について簡単な解説がありました。

まず始めに大事なこととして、

AWSを利用する際は「このサービスをどう使おう？」で悩まずに「こういう事がやりたい」で考えてほしい。そして「こういう事がやりたい」を出来るかどうかを気軽にSAに相談してほしいとのこと。

AWSに触れる際、安心してほしい事として、

AWS社ではセキュリティ面を一番重要視しているということ
コストは利用した分だけ掛かる反面、AWS社では顧客のコストをどのように落としたのかが評価される文化があるということ
現在、160以上のサービスがあるが全てを覚える必要はないこと
- (言ってしまえば、SA自体も全ては把握していないとのこと)

そしてAWS社のカルチャーについての説明がありました

AWSでは「全員がリーダーである」であること
CEOのジョブ・べゾスが提唱した「2枚のピザ理論」についての話

また、AWSのマネージドサービスの学び方としては下記の順で見ていくと理解が深まりやすいとの事。 1. 「[AWSドキュメント]」を見る 2. 「よくある質問」で出来る事を把握 3. 「AWS ブラックベルト」でSAが説明している動画を見て詳しく学ぶ 4. 「AWS - SA」の方に気軽に質問する ← ココとても大事

ちなみに弊社Slackに存在しているAWSに関して聞くことができるチャンネルでは、AWSのソリューションアーキテクトの方に対して質問する事ができ、個人的なAWS利用だったとしても気軽に質問してもらってOKなのでバンバンしてくださいとの事でした。

これはとても良い情報。

#3.「ECSを基本とした各AWSのマネージドサービス」について

登壇者 : 千葉悠貴 (ちばゆうき) さん / AWS ソリューションアーキテクト
概要 : ここから、ECSを基本とした基本的なAWSのマネージドサービスの座学が開始されました。

Amazon Virtual Private Cloud （VPC ）の解説

登壇者 : 千葉悠貴 (ちばゆうき) さん / AWS ソリューションアーキテクト

20190313 AWS Black Belt Online Seminar Amazon VPC Basic from Amazon Web Services Japan

こちらではソリューションアーキテクト千葉さんより、

オンプレでネットワークをどう構成していくか？
これがクラウドに変わることでどうなっていくのか？
VPCを活用する際に考えること

これらについて座学形式で説明していただきました。

こちらのセッションで、VPCはAWS上に構築できるPrivateなネットワークであるという事の説明と、VPCを利用する上で出てくるキーワード、利用方法について説明がありました。

Public subnet / Private subnet
Inbound / Outbound
NAT Gateway
Security Group / Network ACL
Region / Availability Zones （Multi AZ）

基本的なアプリにおいてFWは「セキュリティグループ」を利用するだけで問題がない。

また、Regionをどのような観点で選定するのかについては「どれほどのレイテンシが必要なサービスなのか？」と「サービスの性質・法規制等を考慮してどの国に配置するのが適切なのか」を考えること。という事を仰ってました。

個人利用で何か作りたい程度であれば「Oregon Region」を利用するだけで問題がなさそうだなと言う発見をしました。

Amazon Elastic Compute Cloud （EC2）の解説

登壇者 : 千葉悠貴 (ちばゆうき) さん / AWS Japan ソリューションアーキテクト

20190305 AWS Black Belt Online Seminar Amazon EC2 from Amazon Web Services Japan

EC2はAWS環境上に伸縮性のある仮装マシンを用意できるサービスで、Linux、Windows、Red hat等のさまざまなOSの仮装マシンの環境を即座に用意する事が可能。

オンプレでマシンを用意するのとは異なり、PCを用意した後に各種セットアップを行なってアプリケーションサーバー等として利用できるようにするまでにかかる時間を最小限にする事ができる。

このEC2はインスタンスという単位で構築する事ができ、各OS、用途別、スペック別に複数のインスタンスが存在しており、高GPUが必要な演算用途、アプリケーションサーバー用途など多岐に渡った種類が用意されている。インスタンス選択の際は、後世代のものが性能・コストが最適化されているため、そちらを選んだほうが良いとの事。

ちなみにモニタリングツールであるCloud Watchと組み合わせると、アラートが起きた場合にAuto Scalingを行うような設定にしておけば、CPU使用率・トラフィックの増減に合わせてインスタンスの数を増減する事が可能。(これについてはAutoScalingで記載)

ボタンひとつから数十秒待つだけで、すぐ利用できるサーバーが用意できるのはすばらしいですね。

Auto Scalingとは

登壇者 : 千葉悠貴 (ちばゆうき) さん / AWS ソリューションアーキテクト

AWS Black Belt Online Seminar 2017 Auto Scaling from Amazon Web Services Japan

クラウドならではのオートスケール。これは、状況に合わせてVPCインスタンスを増減する事が可能なサービスで、

オートスケーリンググループ(ASG)を作成して、その状態をCloud Watchに送信
設定したしきい値を超えたものがあれば、Cloud Watchアラートが発動。
発動したアラートがAuto Scalingに伝わりASGに作用する。

というようなスケールイン、スケールアウト、クールダウンを適切に行える状態を保つ事によって、パフォーマンスの最適化、不要なリソースの削減、コストの削減を達成する事ができる。

ただ、突然のスパイクには向いていないので、負荷が高まった場合は静的ページに逃がすなどの対応を考えた方が良いとのこと。

オンプレの場合は、負荷に合わせてマシンを追加購入しないといけないですが、利用しなくなった場合は無駄なコストがかかってしまうので、余計なコストをかけずに必要な分だけ費用をかける事が出来て良いですね。

Amazon Container Servicesについて

登壇者 : 千葉悠貴 (ちばゆうき) さん / AWS ソリューションアーキテクト

20180220 AWS Black Belt Online Seminar - Amazon Container Services from Amazon Web Services Japan

下記のサービスたちの事を包括してこのように呼ぶ。

- Amazon Elastic Container Registry（ECR） 
- Amazon Elastic Container Service（ECS） 
- Amazon Elastic Container Service for Kubernetes（EKS）
- AWS Fargate

名前の通りコンテナを利用するサービスで、これらを組み合わせる事で手元のコンテナをそのまま本番にあげる事ができる状態を作る事が可能になる。

具体的にはこのような流れを行っていく

ECRでコンテナイメージを保管して
ECS / EKSを利用する事でコンテナの構成管理を行い
CodeBuiud4兄弟を利用して、コンテナがVPCにアップロードされる状態へ

ちなみにECSやEKSはコンテナオーケストレーションサービスと呼ばれ、複数のコンテナを管理するサービスのことで、Dockerの起動や編集、停止などを実行することが可能。

ちなみにAmazon Elastic Container Service for Kubernetes（EKS）は、 GoogleがOSSで開発したKubernetesをAWSで利用する事ができるサービスだが、 Kubernetes時代がOSSのため、何か新しい変更を加えたい場合は先にOSSへのコミットが必要になってしまう関係上、EKSへの変更は少し時間がかかる。これが許容できない場合はAmazon Elastic Container Service（ECS）を選択すると新しい機能実装は早いとの事。

こういったコンテナ一貫型開発ができる状態にする事で、開発者がインフラ周りの整備・運用を考えなくて良くなるのは非常に嬉しいですね。

Amazon Relational Database Service（Amazon RDS）について

登壇者 : 桑野章弘(くわのあきひろ) さん / AWS ソリューションアーキテクト

20180425 AWS Black Belt Online Seminar Amazon Relational Database Service (Amazon RDS) from Amazon Web Services Japan

AWSが管理するリレーショナル・データベース・サービス（RDS）の略称で、オンプレミス型のRDSや、VPC、ECSなどと異なりハードウェア、データベース運用・管理をAWS側で行ってくれる事で、データベース管理者（DBA）がより付加価値の高い仕事に集中する事ができるようになる。 - ちなみに付加価値の高い仕事とは「特性理解」「パフォーマンス・チューニング」「（ログを見て）問題特定、検証」など

オンプレの場合

特徴として、RDSが稼働しているハードの用意からDBのインストール・設定まで全部行う必要がある。

on ECSの場合

ハード的な部分はAWSが管理しているため、面倒を見なくて良いが、DBのインストール、運用、管理を行う必要がある。

Amazon RDSの場合

ハード、DBの用意、運用、管理までAWS側が行うため、気にする必要がない。
ただし、AWS側で管理している特性上、バージョンが限定されてしまったりする等のデメリットはあるので、そこをどうにかしたい場合はECSを選択すると良い。

ちなみにここらへんのDBをどのように設計すればよいのか？という所に関しては、「RDS アーキテクチャ」で調べると色々出てくるとの事。

RDSに関しては、これまであまり触る機会がなかったので、まずは学習がてらアプリケーションを作る時にRDSを使ってみたいと思います。

Amazon Auroraについて

登壇者 : 桑野章弘(くわのあきひろ) さん / AWS ソリューションアーキテクト

AWS Black Belt Online Seminar 2017 Amazon Aurora from Amazon Web Services Japan

RDSの解説が終わった後は、Auroraについての説明。一言でいうと「いたせりつくせりなハイパフォーマンスRDS」です。

特徴としては下記の通り

スループットがMySQLの5倍 / PostgreSQLの3倍（講義時点では）
データは3箇所のAZに格納され、1つのAZにつき2箇所のディスクに書き込み
合計3つのAZ。6箇所に格納される事により、障害時にダウンタイムが出ない

自分自身、Auroraに関しては名前だけは聞いた事がある状態で、どういったサービスなのかよく分かっておりませんでしたが…

ある程度のパフォーマンスが求められつつ、冗長性もあるものを即座に用意したい場合は迷わずAuroraを選択して良さそうだなという印象を持ちました。

Amazon ElastiCacheについて

登壇者 : 桑野章弘(くわのあきひろ) さん / AWS ソリューションアーキテクト

AWS Black Belt Online Seminar 2017 Amazon ElastiCache from Amazon Web Services Japan

ElastiCacheについての説明。これは、AWSの管理しているインメモリ型のマネージドサービスで、一時的に保存したい情報をRedisやMemcachedに保存する事ができる。

ちなみにAPPサーバからDBサーバに直接クエリを飛ばした場合は、DBサーバで都度応答を返すが、ElastiCacheが定期取得した情報内に求められた情報があればAPPサーバに情報を返却し、情報がない場合はDBサーバに情報を取得して返却する動きを行う。これらは高スループットかつ、低レイテンシなため、DBサーバーの負荷軽減、パフォーマンス向上につなげることができる。

各エンジンの特徴としては、

Amazon Elastic Cache for memcached

メモリに収める機能なのでバックアップする事はできない。
- どうしてもバックアップしたい場合は、エクスポートするスクリプトなどを別途用意して定期実行するのがよい。
スケールアウトする場合はコンシステントハッシュ法（アルゴリズム）で考えると良いらしい。
Auto Discoveryに対応した専用のClient LibraryがAWSから提供されている
- 「Java」「 PHP」「.net」の言語が存在している

Amazon Elastic Cache for Redis

こちらは、Snapshotベースでのバックアップ・リストアに対応している
AWSからは専用のLibrary提供していないのでRedisのものを利用するとよい

との事。

ちなみに、memcachedを触った事がない事もあり、Redisのほうがとっつきやすそうだなぁという印象が強いです。（あと、呼び方をずっと”Elastic Cache”だと思ってたんですが、”ElastiCache”だったんですね）

Amazon DynamoDBについて

登壇者 : 桑野章弘(くわのあきひろ) さん / AWS ソリューションアーキテクト

AWS Black Belt Online Seminar 2017 Amazon DynamoDB from Amazon Web Services Japan

DynamoDBは、一言でいうと「どんな規模にも対応する高速で柔軟なNoSQL」です。

特徴としては下記の通り

単一障害点（SPOF）の存在しない構成で考えられており、データは3箇所のAZに格納され信頼性が高い
テーブルごとにRead/Writeそれぞれに対して必要な分だけのスループットキャパシティを割り当てる事ができる
　ストレージの容量制限が存在しないため、ディスクやノードの増設を行う必要がない

DynamoDBについても名前だけしかしらなかったのですがこの座学を通して、ものすごいNoSQLフルマネージドサービスだという事を知る事ができました。

AWS Identity and Access Management（AWS IAM）について

登壇者 : 千葉悠貴 (ちばゆうき) さん / AWS ソリューションアーキテクト

AWS Black Belt Online Seminar AWS Identity and Access Management (AWS IAM) from Amazon Web Services Japan

このIAMはAWSを利用するユーザーに対して、安全にAWSサービスを利用できるようにするための仕組みを提供するサービスです。

詳細については資料に記載の通りですが、AWSのサービスを利用する上でかなり重要なものなので、推奨された設定項目について適切な対処を行ってほしいとの話しがありました。

これらを怠る事で、管理しているサーバを踏み台サーバやマイニングサーバとして悪用されるケースも存在している

#4. Docker入門ハンズオン

登壇者 : SREチーム大木裕介さん（[@_y_ohgi] ）/ 合同会社 : DMM.com
概要 : Dockerの有用性、活用方法をハンズオンを通して学びます。

[入門 Docker]

こちらのセッションでは、大木さんが作成された「入門Docker」の内容について解説を交えながらハンズオンが行われました。

詳細については資料内に記載されているので割愛しますが、前述のDMM型SREをAWSのフルマネージドサービスを用いて実現する際に必要となるコンテナについての技能をDockerを触る事で取得していくという内容で、実際に概念説明から、イメージ・コンテナの作成もプロダクションで利用するためのベストプラクティスについての解説がありました。

これまでDocker = docker-composeじゃないの？ぐらいの理解度だったので、 Dockerイメージは基本的に「1プロセス = 1コンテナ」で作成し、複数のDockerを扱うためにオーケストレーションツールである「docker-compose」や「swarm」「ECS」「Kubernetes 」を利用して複数のdockerの管理等を行うという事を知ることができ、色々と腑に落ちた体験をする事ができました。