よりよくawsを使う方法をシェアするawswakaran.tokyo #2に参加してきました。
自分もなんとなくawsしてるところもあるのでちゃんとする意味でも学びに参りました。
「なんとなく」使うクラウドから「ちゃんと」使うクラウドへの入門
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は同時接続数制御して、一定の接続数がきたらソーリーサーバに飛ばすといったことはできないのか？
- 作り込めばできます。
- コネクション数でさばける数だけ制御するのはマネージドサービスでは難しい
そのコンテナ化、本当に嬉しいですか？
- 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 誕生以来本番運用しつづけてわかったこと
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のバックエンド
- 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エラー増加
- ALBのリクエストはAWS WAFへ転送されて、リクエストのブロックや許可を行うが、障害が発生したときは、障害が発生したAZのWAFへルーティングされると障害が起こっていた。
- 対応としてはWAFを無効にするか、ALBのサブネットから問題が起きたリージョンを外してリクエストを飛ばさないようにする
障害時の情報源
- AWS Personal Health Dashboard
- AWS Service Health Dashboard
- 探しやすく一覧性があるが、情報は即座には反映されない
- Twitter
Atlantisで実現するTerraformのGitOps
Infra as Codeのおさらい
- インフラをコード化する利点
- 再現性をもたせた環境構築
- コードを見ればインフラの設定がわかる
- チーム内で知見共有できる
- 加えた変更の履歴が残る
- 変更適用前のレビューの必須化ができる
Terraformの変更適用の自動化の必要性
- terraformでインフラ構築したあとは,,,
- システムの改修に対応する
- awsの新機能を導入
- 障害から得られた知見の反映
- 知識向上によって気づいた負債対応
- 変更が何度も発生するということは何度もコード変更を適用する
- Terraformの変更適用も自動化したい！
- 変更時のログも残してチーム内に役立てたい
Atrantisの紹介
全体的に広くざっくりawsについての知見を深められるような発表でした。
アプリケーションエンジニアからみたAWSへの視点もあったので幅広くしれました。
個人的にはfirebase hostingしていたときにBasic認証するのにとても苦戦する感じだったので、Amplify ConsoleのHostingでBasic認証できるという点にとても感動しておりました。
View Comments
Your point of view caught my eye and was very interesting. Thanks. I have a question for you.
Thanks for sharing. I read many of your blog posts, cool, your blog is very good.