kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

Dockerのmemory, memory-reservation について

docker
  • memory : ハードリミット。ここで指定した以上のメモリを使用しようとするとOOMKillerが走る
  • memory-reservation : ソフトリミット。ホストのメモリに余裕がある時は、これ以上使用することもある
    • 余裕が無いときは、memory_reservation 内にとどめる
    • ECSでは設定上のこの値を見て、ホストにコンテナを追加できるか判断する

AWS 認定ソリューションアーキテクト – アソシエイト (新版) 対策メモ

AWS

自分が知らなかったAWS用語のおぼえがき

Amazon Redshift

Amazonが提供するデータウェアハウス

データウェアハウス（DWH）とは、意思決定のために、基幹系などの複数システムから、必要なデータを収集し、目的別に再構成して時系列に蓄積した統合データベースで、データ分析や意思決定に役立てます。

Redshift 拡張VPCルーティング

VPCエンドポイントやゲートウェイと接続したい場合に設定する必要がある

Amazon Glacier

アーカイブに最適な低コストのオブジェクトストレージ

  • 耐久性 99.999999999%

アーカイブの取り出しオプション

  • 迅速 : 250 MB 以下のアーカイブ 1〜5 分以内で取得可能
  • 標準 : デフォルト。 3〜5 時間で取得可能
  • 大容量 : 5〜12 時間で取得可能。安い

Vault Lock

ロックを掛けて、以降そのデータの編集を不可能にする仕組み。 コンプライアンス目標を達成しやすくなります とのこと

Amazon S3

PUTできるファイルのサイズ制限は5G

アクセス制限

  • バケットポリシー : IAM、バケット単位で制限
  • アクセス・コントロール・リスト(ACL): AWSアカウント単位で、バケット/オブジェクトのread/writeを制限できる
    • 削除権限の制御はない
  • IAM ポリシー: S3へのAPIアクセスを制限

S3 MFA Delete

オプションでオブジェクトの削除にMFAデバイスによる二段階認証をできるようにする

オプションで有効な機能

  • オブジェクトの暗号化
  • アクセスログの取得
  • オブジェクトのバージョニング

暗号化

KMSを使って、いろいろな方法で暗号化できる

高速化のベストプラクティス

ファイル名の先頭にランダムな文字列を入れると、格納先のパーテーションが分散して、速度が上がる

  • S3はオブジェクトをキー名毎にアルファベット順に、複数のパーテーションに格納している
  • タイムスタンプやアルファベット順のキーを大量に作成すると、特定のパーテーションにアクセスが集中して、速度が低下する

リクエスト率およびリクエストパフォーマンスに関する留意事項 - Amazon Simple Storage Service

古いノウハウになってしまったが、テストではそのままなので残す...

Amazon EBS

AWS KMSを使って、ディスクの暗号化ができる

ボリュームの種類

汎用SSD

価格と性能のバランスが良い

  • 容量: 1G〜16T
  • 最大IOPS: 10,000

プロビジョンドIOPS SSD

高スループット&高価

  • 容量: 4G〜16T
  • 最大IOPS: 32,000

スループット最適化HDD

低コスト&低性能 ブートボリュームにはできない

  • 容量: 500G〜16T
  • 最大IOPS 500

スループット最適化HDD

ブートボリュームにはできない

さらに低コスト&低性能

  • 容量: 500G〜16T
  • 最大IOPS 250

Amazon EBS ボリュームの種類 - Amazon Elastic Compute Cloud

Amazon EFS

EC2インスタンスに紐づけできるファイルストレージサービス

Amazon EFSを使ってみた（前編） - 株式会社ネディア

Amazon ECS

タスクのIAMロール

タスクにIAMロールを紐づけることができる

異なるユーザのタスクを1つのクラスタで実行しても、権限のないコンテナやサービスへの接続を制御することができる

AmazonCloudFront

Amazon CloudFront は、静的および動的なウェブコンテンツ (.html、.css、.js、イメージファイルなど) をユーザーに高速に配信するウェブサービスです。

キャッシュを破棄するのに10分ほどかかるので、リアルタイム性が求められるデータには向かない

AWS CodeBuild

CIサービス

AWS CodeDeploy

EC2などのAWSサービスへの自動デプロイサービス

AWS Cloud​Formation

クラウド環境内のすべてのリソースを記述してプロビジョニングするためのツール

  • terraformとよく比較される

AWS STS

AWS Security Token Service

AWS リソースへのアクセスを制御できる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。

一時的なIAMを作るようなサービス

Amazon SQS

メッセージキューサービス

Amazon SNS

プッシュサービス、SMSやメールやアプリへのpushができる

Amazon Kinesis

大規模なストリーミングデータを処理するサービス

EC2で直接受けたり、SQSで受けるよりも安く、スケールするらしい

Amazon EMR(Elastic MapReduce)

分散処理基盤

ETL(雑多な情報をデータウェアハウスにまとめる処理)向け

EC2でClusterを作ってくれる(インスタンスタイプと台数を指定できる

Map Reduce とかの分散コンピューティング用の実装が必要

AWS Batch

EMR と違って、分散コンピューティング用の処理は不要

Amazon Aurora

MySQL や PostgreSQL と互換性のあるリレーショナルデータベース

  • 最大テーブルサイズは64TiB
  • RDSのテーブルのファイルサイズは最大16TiB

[Amazon RDS]

ポイントインタイムリカバリ

自動バックアップからの復帰のこと

サポートエンジン

PostgreSQL、MySQL、MariaDB、Oracle、Microsoft SQL Server

  • DB2は未サポート

AWS Direct Connect

  • インターネットVPN: 安い、遅い、即時に設定可能
  • 専用線: 高い、速い、設置に数週間

Amazon Kinesis

データストリームの処理基板

  • 最大ファイルサイズが1GiB

EC2関係

EBS BackedインスタンスとインスタンスストアBackedインスタンス

スポットインスタンス

AWSで余剰したインスタンスを格安で利用できるが、確実に取得できるとは限らないので 問題の用途によっては不適なインスタンスタイプ

料金設定が上限を超えたり、そもそもインスタンスがなくなった時等に強制終了される

  • 2017年までは、1時間以内に強制終了された場合は無料だった。現在は秒課金

Cloud Watch 関係

Amazon EC2 メトリクス

標準メトリクスは以下のとおり

  • CPU クレジット利用数（CPUCreditUsage）
  • CPU クレジット累積数（COUCreditBalance）
  • CPU 利用率（CPUUtilication）
  • １秒あたりの Disk 読み込み回数（DiskReadOps）
  • １秒あたりの Disk 書き込み回数（DiskWriteOps）
  • インスタンスストレージの読み取りバイト数（DiskReadBytes）
  • インスタンスストレージの書き込みバイト数（DiskWriteBytes）
  • 受信したバイト数（NetworkIn）
  • 送信したバイト数（networkOut）
  • OS・インフラストラクチャステータスチェックの成功・失敗（StatusCheckFailed）
  • OSステータスチェックの成功・失敗（StatusCheckFailedInstance）
  • インフラステータスチェックの成功・失敗（StatusCheckFailedSystem）

基本モニタリング

無料

ステータスチェック系は1分間隔 他は5分間隔

詳細モニタリング

有料

全て1分間隔でモニタリングできる

Auto Scaling グループ

  • クールダウンタイム: インスタンスが起動してから準備完了になるまでの時間を指定できる
  • 終了ポリシー: 最初に終了するインスタンスを指定できる、作成日が古い/新しいなど

ロードバランシング関係

ELBはマルチリージョン不可

Weighted Round Robin (WRR

Route53の機能。マルチリージョンでロードバランシングするならこっち

設定した割合でラウンドロビンされる

ネットワークACL関係

ネットワークACLとセキュリティグループの違い

ネットワークACL

セキュリティグループ

AWSのネットワークACLとセキュリティグループの違い - プログラマでありたい

0.0.0.0/0 の意味

ワイルドカード

一時ポート(エフェメラルポート)

TCP/IPにて、通信の帰りに特定範囲のポートを使用する ネットワークACLでは、エフェメラルポートのイン/アウトバウンドを許可する必要がある

ネットワーク ACL - Amazon Virtual Private Cloud

VPC関係

VPCエンドポイント

プライベートサブネットから、インターネットを経由せずにS3やRedshiftにアクセスする仕組み

VPCルートテーブルで、S3やRedshiftへアクセスするときのIPアドレスを、VPCエンドポイントに設定する

インターネットを経由しない分、よりセキュアにS3やRedshiftにアクセスできる

プライベート、パブリックサブネット

サブネットのトラフィックがインターネットゲートウェイにルーティングされる場合、そのサブネットはパブリックサブネットと呼ばれます。

インターネットゲートウェイへのルートがないサブネットは、プライベートサブネットと呼ばれます

NATゲートウェイ

プライベートサブネット内のインスタンスから、インターネットに接続するためのゲートウェイ

逆にインターネットからは、プライベートサブネットに接続できない

インターネット側へのトラフィックはNATのIPアドレスになる

インターネットゲートウェイと、NATゲートウェイの違い

NATゲートウェイは、プライベートサブネットとインターネットゲートウェイの仲介をするゲートウェイ

ルートテーブル

コンピュータネットワークにおけるルーティングテーブルとは、ルーターやネットワーク接続されたコンピュータが持つ、個々のネットワークの宛先への経路の一覧を保持しているテーブル状のデータ構造である。

MHA for MySQLのデフォルトのヘルスチェックでは、DBの書き込み障害ではフェイルオーバーしないよというお話

MySQL MHA

先に結論

MHA for MySQLのデフォルトのヘルスチェックでは、DBの書き込み障害ではフェイルオーバーしない

なんで?

  • MHAはヘルスチェックをバラメータ ping_type で設定された方法で行う
  • ping_type のデフォルトは SELECT
  • ping_type : SELECT の場合、ヘルスチェックは SELECT 1 As Value で行うので、書き込み障害には気づけない

どうすればよいの?

ping_type : INSERT の場合の注意事項

感想

書き込み障害が発生したのに、フェイルオーバーが行われず、めちゃくちゃ焦った

ツールが想定通りの挙動をしなかった場合、公式ドキュメントとコードをじっくり読もう

SRE本読書メモ エラーバシェットの話しを読んで、明確な数値目標は意思決定コストを下げると思った

読書メモ

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

なぜ数値目標を決めるのが大事か?

明確な数値目標は、意思決定コストを下げる

数値を決めることで意思決定コストが下がる例

  • エラーバシェット

エラーバシェットとは?

チーム内で合意が取れた、一定期間内に許容できる予定外のシステムダウン時間の合計

なぜエラーバシェットがあるのか

機能追加と信頼性向上どちらに注力するか悩むことが無くなる

  • エラーバシェットに余裕がある間は、機能追加にリソースを割く
  • 逆に、いまのままだとエラーバシェットが無くなりそうならば、信頼性向上にリソースを割く

信頼性向上の施策の優先順位に悩むことが無くなる

たとえば、ある障害のリカバリに掛かる時間が、どれだけエラーバシェットにインパクトを与えるか? で判断できるようになる

  • エラーバシェットが15分なのに、リカバリに30分掛かるならば、それは必ず自動化すべきと判断できる

過剰な信頼性向上をしなくなる

  • SLA 100%は実現不可能
  • 一定以上信頼性を上げるのには、指数関数的に開発コストが上昇する

感想

  • スプリント計画時にエラーバシェットをチェックすると、次やるべきことが明確になりそう

SRE本読書メモ 15章: ポストモーテム文化。非難のない振り返りが改善を生む

読書メモ

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

非難のない振り返り

googleでは、インシデントから学びを得るために ポストモーテム (検死) と呼ばれる振り返りを行う文化がある

なんで非難しない振り返りが重要なの?

  • 非難は人が変わることを強要することだが、人は人を変えることはとても難しい
  • 人を変えることは出来ないが、その人が正しい判断をすることを助ける仕組みを作ることはできる
  • 非難を避けようと、インシデントや問題を隠蔽するようになる

ヘスルスケアや航空業界など、些細なミスが大事故に繋がる業界で生まれた文化

ポストモーテムの意義

  • 再発の可能性を削減するための効果的な予防策が確実に導入されること
  • 記録することで、他のチームもそれを参照して、問題を予防できるようになる

ポストモーテムのゴール

ポストモーテムのゴールは事前にチームメンバーに共有されていることがだいじ

  • 後々の分析のために必要なデータは収集されていること
  • サービスへの影響(インパクト)の分析が完全に行われていること
  • 根本原因がしっかり分析されていること
  • アクションプランの内容と優先度は適切であること
  • 結果をステークホルダーに共有できていること

ゴールの条件を満たしているか、かならず上級エンジニアからのレビューを受けること

ポストモーテムのテンプレ

* 作成日:
* 作者:
* ステータス: (現在のステータスを書く
* サマリ: (概要を書く
* 根本原因:  (発生要因に書かれた現象が発生した根本的な原因を書く
* 発生要因: (例: トラフィック突然の増加で表面化した潜在的なバグ
* 対応: 
* 検出: (なにを検出した事でインシデントに気づいたか?
* アクションアイテム: (改善、再発防止の為に取る/取ったアクションの一覧

# 教訓
## うまくいったこと
## うまくいかなかったこと
## 幸運だったこと

# タイムライン

(発生から改善までの時系列を書く

# 参考情報

感想

  • 「人を変えることは出来ないが、その人が正しい判断をすることを助ける仕組みを作ることはできる」だいじ
  • 他チームへの共有を意識したポストモーテムだいじ

[SRE本読書メモ] 13章: 障害対応。ストレスの無い障害対応が少ないダウンタイムを生み出す

読書メモ

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

言いたいこと

障害対応時のストレスを減らすことで、(人を含めたシステムの)信頼度を上げることができる

なので、ストレスを減らす施策を積極的に打ちましょう

なんでストレスの無い障害対応がだいじなの?

  • ストレスホルモンが生じると、人間は、認知機能が下がり、直感・反射で動くようになる
  • 障害対応は、実測→仮説→検証の繰り返しなので、感や経験で動いても良い結果を生み出さない
  • そのため、理性的な障害対応を行えるようにするためには、担当者にいかにストレスを生じさせないかがキモになる

どうすれば、ストレスを感じずに障害対応ができるようになるの?

以下のようなことを予め準備/共有することで、担当者の負担感を下げ、心理的安全性が確保できる

  • 明確なインシデント管理の手順
  • インシデント発生時の役割分担
  • 振り返りでは避難されないことを明示(後述

インシデント発生時の役割分担

役割分担を明確にすることで、メンバーの負担感を下げ、それぞれが正しい目的に注力できるようになる

  • 責任者: 他メンバーへの責任の割当、作業効率の障害を取り除く、ライブインシデント対応ドキュメントの作成
  • 実行担当: インシデントに直接対応するメンバー
  • コミュニケーション: 公の顔。チームとステークホルダーに状況を共有し続ける役割
  • 計画: 長期的な課題を扱う。引き継ぎの調整、夕食の発注、最終的に通常の状態に戻す準備など

ストレスを減らすために個人的にできること

  • 「障害が発生したからといって世界が終わるわけではない」ということを意識する
  • 自分の感情に注意を払う。パニックや圧倒されているという感覚が生じたら、メンバーに支援を求める

感想など

  • 障害対応のストレスから人間の認知機能の話が出たのが興味深かった
  • 振り返りときに対応者が「どこにストレスを感じたか?」を記録すると、仕組みの改善の余地が見えそう
  • 自分も障害対応時には、視点が狭くなったり、ステークホルダーとの共有がおろそかになる。それを減らすためなに、役割の分担を次回の障害対応時にやってみたい

RubyでGCしても直ちにRSSが減るわけではないというお話

Ruby

先に結論

  • GCをしても、RSSが直ちに減るわけではない
  • C言語のレイヤーで、free しても次の malloc に割り当てるためにメモリを手放さない実装があるのが原因らしい

計測してみた

適当な長さのStringを10000回作って、RSSと、ObjectSpace.memsize_of_all を計測する

require 'objspace'

puts ",ObjectSpace.memsize_of_all,RSS"
1.upto(10000) do |i|
  a = "10"*10000
  a += '123'
  rss = `ps -o rss= -p #{Process.pid}`.to_i * 0.001
  memsize_of_all = ObjectSpace.memsize_of_all * 0.001 * 0.001
  puts "#{i},#{rss},#{memsize_of_all}"
end

結果

以下のグラフの通り

memsize_of_all は数ループに1回GCされているが、実際にプロセスがメモリを手放すタイミングはもっとゆっくりしている

f:id:kasei_san:20180517221213p:plain

単位はMB

なんでGCしても、RSSはすぐに減らないの?

stackoverflowだけれど納得感のある解説を見つけた

Cレベルの話をすると、free を呼んでもOSにメモリを返さず、次に malloc した際に再割当するような実装も多く存在します。 ということで、一般的にはメモリの解放によっても占有メモリが減らない前提でプログラミングすることになろうかと思います。

2018/05/18 追記

会社のひとから、上記のコメントは Conservative GC と混同しているのではないか? とご意見頂いた

参考リンク