awswakaran.tokyo #2 @ドリコムに参加してきたレポート

公開日：2019/09/25

よりよくawsを使う方法をシェアするawswakaran.tokyo #2に参加してきました。

自分もなんとなくawsしてるところもあるのでちゃんとする意味でも学びに参りました。

「なんとなく」使うクラウドから「ちゃんと」使うクラウドへの入門

Twitter

https://twitter.com/kuro_m88

~~https://twitter.com/kuro_m88~~

AWSを例にかなりざっくり説明します

クラウドとは?

クラウドは概念図で表されてサービス構成はわかりやすいが、実際はどうなっているのか？
実際のクラウドはデータセンターにサーバを並べて、各種サービスがデプロイされていく
- 一つの物理ホスト上で様々なユーザ向けのサービスが実行される
- マネージドサービスも大きなリソースの中で動いている
サーバを増やしたりしている塊がアベイラビリティーゾーン（AZ）となる
- これを複数個構成し、レイテンシ的には問題がない距離に置く
- AZとインターネットの間はトランジットセンターを通して接続される
- これらの塊をまとめたのをリージョンといい、複数のリージョンでクラウドを構築するとマルチリージョンになる
クラウドとは、巨大なサーバ、ストレージの中でサービスが提供されている環境のこと
- リソースを共有できるので利用効率がよい
- 高度に抽象化されているため、どのサーバで稼働しているかというより、サービスの組み合わせやサービス間の接続に注目した構成図で会話がされることが多い
知っておくといいこと
- AZ Aだけでサービスを提供していた場合、AZ-Aで障害が起きるとサービスがとまるが、LBを使って複数AZにふっていれば問題ない

「ちゃんと」使うには？

ドキュメントを読む
- 使うサービスは最低限一度は目を通すべき
- 英語版のほうがupdate早かったり情報が正確だったりするので、最新版は英語がおすすめ
仕組みが想像できるかどうか
- ドキュメントを読み込んでいれば検討/設計/導入する上で気になる部分/気にするべき部分がおのずと明確になる
責任共有モデル
- クラウドの事業者はあるサービスで定義された部分までを動いたりアップデートするなどの責任をとっていて、その上でお客さんがサービスを実装していく
- サービスがどこまで作っていて、どこからは責任をもって作らないといけないのかという考えを持っておく
SLA
- クラウド事業者と顧客との責任範囲の定義と責任を果たせなかった場合の対応
- EC2の場合、複数のAZが使用不能となることいい、月の99.99%のSLAを下回れば、ユーザが請求したら一部返金をうけれる
- SLAがないサービスもある
リスクを認識する/許容する
- 3AZ構成のアプリケーションにおいて、1AZがダウンして負荷に耐えきれなくてサービスダウンすることは起こり得る
- そこで、オートスケールで他のAZでリソースをまかなうようにするが、AZごと障害がおこると、急激な負荷の対応しようとサーバを増強し始めAZ内のサーバの在庫が不足して起動に失敗したりする
- そのため、常に必要なキャパシティの150%のリソースを投入して置かなければならない
- クライアントサイドでのリトライやサービスの縮退機能によって提供レベルを下げたりして作り込むのが現実的
- 障害が起きたときにどれくらい障害が起こるか、損失、信用などの防ぐことにかけるコストとバランスを考えてどこまで求めるかを選択する
- 一般的におこりうる事象はミドルウェアやクラウドサービスのドキュメントに書かれていることが多いので、ドキュメントを読み込んでおきましょう

興味がある人向け情報

re:Inventというイベントを毎年開催していて、サービスの裏側や設計思想について語るセッション（大体youtubeに上がってます）があり、それを知っておくと理解が深まって考え方が身につく
実験してみる
- 分離した環境で障害を起こしたり再起動させてみたりしてみる
- ドキュメント通りの共同をしているか、自分の理解とあっているかを確かめる
- 例えば、LmabdaやS3の障害の挙動を確かめることは不可能
真似をしてみる
- マネージドサービスが自動で行ってくれるようなことを自前でやってみる
自宅サーバを始める
- 自宅は簡単に障害が起こり得るが、障害が起きても被害が限定的
- 例として、自宅サーバで1200コンテナ起動したらIPアドレスの割当レンジを使い果たしてIPアドレスが枯渇してインターネットにつながらず家族に怒られたことがありました

QA

LBは同時接続数制御して、一定の接続数がきたらソーリーサーバに飛ばすといったことはできないのか？
- 作り込めばできます。
- コネクション数でさばける数だけ制御するのはマネージドサービスでは難しい

そのコンテナ化、本当に嬉しいですか？

Twitter

https://twitter.com/euxn23

~~https://twitter.com/euxn23~~

そのコンテナ化、本当に嬉しいですか？ from Yuta Suzuki

Elastic Beanstalk, ECS, Fargate, EKSなどがあるが、コンテナ化すると、本番と同じ環境で開発ができるようになる。
- 環境構築不要ですぐ使える。docker-composeでコンテナの依存関係もかける
Railsのdevサーバのホットリロードがコンテナと相性が悪い。
- フロントエンドの差分ビルドをwatchすると別のIOシステムをまたいでいるせいでdockerとのI/Oが遅くて辛い
- MySQLだとデータのIOが遅くてローカルテストが落ちたりもする
- 複数アプリケーションを全部8080で建てる設定をローカルでやったりするとぶつかる
アプリケーションをコンテナで開発するには向き不向きはある
ミドルウェアは便利
- 1マシンで複数バージョンのMySQLを使用したい
- javaの依存関係が強すぎるElasticSearchの環境構築をしたくない。
- docker composeで構成管理したい
- メンテされてれば便利。
本番環境と乖離するローカル用コンテナ定義
- ローカル用のDockerfile.devなどのdev向けconfigができて本番環境と乖離する
- なんのために存在するかわからないdocker-composeのコンポーネントが増えたりする
極論としてすべて本番環境にする？
- ストレージのマウントやバックアップとか自前でやるのは辛かったり、コンテナ越しにMaster-Slave組むのは辛かったり、コンテナにするメリットがあるのかといった問題がある
継続的にメンテしましょう
- ローカルに環境構築する苦労や環境開発の苦労をちゃんと考える
- railsであればherokuでも検討できるのではないか
ミドルウェアのコンテナ化  – PaaSとローカルの共通化を諦める必要がある
- ローカル向けの定義を継続的にメンテするか、ローカルのdockerファイルは作らない
- お金に余裕があればdev用のPaaSを用意するのが正しそう
安易にコンテナ化せずに、コンテナ化するメリット・デメリットを考える。

Amplify Console 誕生以来本番運用しつづけてわかったこと

Twitter

https://twitter.com/potato4d

~~https://twitter.com/potato4d~~

AWS AmplifyとAmplify Console

AWS Amplifyは各サービスをラップしたAWS Mobile Hubの後継。
- AWS版のfirebase
- iOS, Android, webに対応
- react, vueとも連携できる専用のフレームワークが存在
Amplify ConsoleはAmplifyのファミリーサービスとなる静的サイトホスティングサービス
- S3 + CloudFront + ACM + Route53のラッパー
- Firebase HostingやNetlifyのようなもの
- Amplifyの設定ファイルを流用して静的サイトのCI/CDが可能
- gitホスティングからの連携とyamlファイルだけで運用も可能

S3 + CloudFront + ACMと比較したAmplify Consoleの利点

静的サイトホスティングにフォーカスしている
- ブランチごとのデプロイとドメイン割り振り
- ベーシック認証もできる
- 環境変数の設定もできる
- デプロイメール通知もできる
比較
- 面倒なメンテナンス作業が不要
- S3のバケット掃除が不要
- CI/CD環境はAmplifyConsoleで担保されている
- CircleCIなどを構築しなくてもいい

Amplify Console特有の嬉しさと悩み

権限やアクセスコントール管理の柔軟性がある
ベーシック認証が気軽に使える静的サイトホスティングがあまりない
- 他の手段の場合、CDN+FaaSしか選択肢がない
  - CloudFront + Lambda@Edge
  - Firebase + Functions
- 運用側としてもAWSのIAMと紐付いているのは嬉しい
ユーザ名とパスワードをコンソールから設定できます
複数の環境の統合管理ができる
- ブランチごとにドメインが紐付いて本番とステージングを同時管理可能

悩み

デプロイ通知があまりフレンドリーじゃない
- メール通知以外のデプロイIntegrationがない
- slack通知させるならメール通知+SES+Lamdaを使う形になる
PRごとにgithubに通知もできない

現時点での静的サイトホスティングの選定の結論

S3 + CF + αでつくるならamplify consoleにしたほうがいい
S3がカバーする用途について性的ホスティングはtoo much
Firebase HostingやNelifyと比較すると優越あるものはある

まとめ

Amplifyには多くの種類がある
Amplify ConsoleはS3 + CloudFront + α
AmplifyConsole独自機能が嬉しい
通知機能が貧弱
AWSでホスティングするならAmplify Console一択になりつつある

大規模障害から見えたAWSのバックエンド

Twitter

https://twitter.com/varu_3

~~https://twitter.com/varu_3~~

2019/8/23 12:36よりap-northeast-1のAZで一定の割合のEC2サーバの停止が発生した
AZの話で、ap-northeast-1aが示すゾーンはアカウントごとに異なる。アカウントごとにZoneIdが識別子となる

その１

EC2インスタスのステータスチェックに失敗した
- 止まるのは3AZのうち1AZのみ
- 大体は強制停止→起動で普及できたが立ち上がらないものもあった
- 立ち上がらないインスタンスをAMIイメージを取得してそのAMIから立ち上げようとも失敗
- EBSスナップショットも取得できない
EC2インスタンスの強制停止はコマンドで–forceオプション付きでstopするか、コンソール上ではstopping中にさらに停止すると強制停止になります
対応策としては、止まったら困るインスタンスは日時スナップショットを撮っておく
- EBSのスナップショットはS3に保存する
- S3は最低3つのAZに冗長化されて保存される
- 障害が発生したらバックアップからインスタンス起動する
- 本番環境はMultiAZ構成にして、オートスケールしなくても台数を固定して、オートスケーリンググループで管理する
- 問題が起きたインスタンスを削除して他のAZで立ち上げる

その２

ElasticSearchのパフォーマンスが低下
NewRelicのメトリクスをみると、memcachedの負荷が微増していたが、memcachedクラスタには接続できていた
cloudwatchメトリクスが正常に取得できていなかった
EC2とEBSを基盤としてmemcachedは動いているので影響を受けた
- RDS, Redshift, ElastiCache、Workspaceなども影響するかも

その３

ALBで5xxエラー増加
- ログを見ると、waf-failedとでていた
ALBのリクエストはAWS WAFへ転送されて、リクエストのブロックや許可を行うが、障害が発生したときは、障害が発生したAZのWAFへルーティングされると障害が起こっていた。
対応としてはWAFを無効にするか、ALBのサブネットから問題が起きたリージョンを外してリクエストを飛ばさないようにする

障害時の情報源

AWS Personal Health Dashboard
- 反映が早い
AWS Service Health Dashboard
- 探しやすく一覧性があるが、情報は即座には反映されない
Twitter
- 情報の精度はバラバラ

Atlantisで実現するTerraformのGitOps

Twitter

https://twitter.com/katainaka0503

~~https://twitter.com/katainaka0503~~

Atlantisで実現するTerraformのGitOps from 理弘山崎

Infra as Codeのおさらい

インフラをコード化する利点
- 再現性をもたせた環境構築
- コードを見ればインフラの設定がわかる
- チーム内で知見共有できる
- 加えた変更の履歴が残る
- 変更適用前のレビューの必須化ができる

Terraformの変更適用の自動化の必要性

terraformでインフラ構築したあとは,,,
- システムの改修に対応する
- awsの新機能を導入
- 障害から得られた知見の反映
- 知識向上によって気づいた負債対応
変更が何度も発生するということは何度もコード変更を適用する
- Terraformの変更適用も自動化したい！
- 変更時のログも残してチーム内に役立てたい