kasei_sanのブログ

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

スレーブのレプリケーションが遅延している時に SHOW SLAVE STATUS でチェックするべき値

前提知識

MySQLのスレーブでは、以下の2つのスレッドを使って、レプリケーションを行っている

  • I/Oスレッド : マスタからバイナリログの差分を取得する
  • SQLスレッド : IOスレッドから取得したバイナリログを元にDBを更新する

SHOW SLAVE STATUS で見るべき値

そもそも起動しているか

  • Slave_IO_Running : IOスレッドの動作有無 Yes なら起動中
  • Slave_SQL_Running : SQLスレッドの動作有無 Yes なら起動中

IOスレッド-SQLスレッド間が遅延しているか

Seconds_Behind_Master を見る

  • Relay_Master_Log_File : SQLスレッドが最後に実行したバイナリログのファイル名
  • Exec_Master_Log_Pos : SQLスレッドが最後に実行したバイナリログのファイル名
  • Seconds_Behind_Master : SQLスレッドとIOスレッドの差異

Seconds_Behind_Master が増えている場合、IOスレッドが渡すバイナリログをSQLスレッドが消化しきれていない

Seconds_Behind_Master が 0 なのに、スレーブが遅延している場合は、マスタ-IOスレッド間の遅延が疑われる

マスタ-IOスレッド間が遅延しているか

以下の値について、マスタの SHOW MASTER STATUS での File, Position と差異を確認する

  • Master_Log_File : IOスレッドが現在最新だと認識しているバイナリログのファイル名
  • Read_Master_Log_Pos : IOスレッドが現在最新だと認識しているバイナリログのポジション

大きく差異がある場合、マスタの変更にIOスレッドが追いつけていない

遅延している場合どうしたら良いの?

MySQLのバイナリログについて解説

バイナリログとは

マスタのDBの 更新命令のみ を記録したログファイル

マスタ/スレーブ間の同期(レプリケーション)で使用する

  • my.cnflog-bin オプションを設定すると、バイナリログが作成されるようになる

バイナリログの保存形式

STATEMENT, ROW, MIXED の3種類がある。binlog-format オプションで設定可能。デフォルトは、STATMENT

  • STATEMENT : SQL文をそのまま保持

    • メリット: サイズが小さい
    • デメリット: 非決定的な命令(後述) が発生すると、マスタ/スレーブ間で差異が生じる
  • ROW : DBの行をどのように更新したか? という情報を保持

    • メリット: 非決定的な命令が発生しても同期を維持できる
    • デメリット: サイズが大きい。大量に更新があるとHDDや帯域を圧迫する
  • MIXED: 非決定的な命令のみ ROW形式で保持

    • メリット: ROW形式のバイナリログより小さいサイズで、非決定的な命令が発生しても同期を維持できる
    • デメリット: STATEMENT形式のバイナリログよりはサイズが大きい 

非決定的な命令とは

ORDER BY が指定されていない INSERT」や UUID()など、結果が固定されていない命令を指す

マスタのバイナリログのステータス確認方法

SHOW MASTER STATUS で確認可能

mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
             File: master-bin.000002
         Position: 1307
     Binlog_Do_DB: test
 Binlog_Ignore_DB: manual, mysql
Executed_Gtid_Set: 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
1 row in set (0.00 sec)
  • File : 現在のバイナリログの格納先
  • Position: バイナリログの座標(ポジション)
  • Binlog_Do_DB : レプリケーション対象のDB
  • Binlog_Ignore_DB : レプリケーション対象外のDB
  • Executed_Gtid_Set : GTIDの値(今回は解説しない)

参考

クイズ形式で rubyのジャンプ構文の挙動をおさらいしてみましょう

全問正解した人は自慢して良いと思います。全5問です。

なお、動作環境は ruby 2.5.0 です

問1 Procの中でbreak

実行結果はどうなるでしょう?

def main
  p = Proc.new{|v|
    p v
    break if v >= 5
  }

  1.upto(10, &p) # & は、ブロックの代わりにProcを渡す命令

  p "finished"
end

main

LocalJumpError

解説

  • breakループから抜け出す命令
  • Proc はループではないので例外が発生する

問2 Procの中でnext

実行結果はどうなるでしょう?

def main
  p = Proc.new{|v|
    p v
    next if v >= 5
  }

  1.upto(10, &p)

  p "finished"
end

main

1
2
3
4
5
6
7
8
9
10
finished

解説

  • next は手続きオブジェクトの場合 手続きオブジェクトから脱出する命令
  • 手続きオブジェクトから脱出するが、 upto のループからは脱出しないので、10まで実行される

問3 Procの中でreturn

実行結果はどうなるでしょう?

def main
  p = Proc.new{|v|
    p v
    return if v >= 5
  }

  1.upto(10, &p)
  
  p "finished"
end

main

1
2
3
4
5

解説

  • return は Procの場合手続きオブジェクトの定義をしたメソッドから脱出する命令
  • そのため、 p "finished" は実行されない

問4 外部で定義したProcの中でreturn

実行結果はどうなるでしょう?

def create_proc
  Proc.new{|v|
    p v
    return if v >= 5
  }
end

def main
  p = create_proc
  1.upto(10, &p)
  
  p "finished"
end

main

LocalJumpError

解説

  • return は Procの場合手続きオブジェクトの定義をしたメソッドから脱出する命令
  • しかし、すでに 手続きオブジェクトの定義をしたメソッド が終了している場合、脱出できないので例外となる
  • こういった、既に生成されたメソッドが終了している手続きオブジェクトを orphan(孤児) と呼ぶ

問5 lambdaの中でbreak

実行結果はどうなるでしょう?

def main
  p = lambda {|v|
    p v
    break if v >= 5
  }

  1.upto(10, &p)

  p "finished"
end

main

1
2
3
4
5
6
7
8
9
10
finished

解説

  • lambdaの場合、 next, break, return 全てが 手続きオブジェクトからの脱出の命令になる

まとめ

手続きオブジェクト

Proclambda のように、ブロックをオブジェクトにしたもの

Proc

  • next : 手続きオブジェクトからの脱出
  • return : 手続きオブジェクトを定義したメソッドから脱出
    • ただし、既にメソッドが終了している場合、LocalJumpError
  • break : LocalJumpError

lambda

next, break, return 全てが 手続きオブジェクトからの脱出

感想

lambdaがなんでこんなやっつけな挙動なのか知っている人いたらおしえてください

参考文献

AWS EC2 の T2 インスタンスについてメモ

先にポイント

T2インスタンスは他と違い、CPUの使用について独特の制限がある(その分安い)

  • T2はインスタンスタイプ毎にCPU使用率が定められている。これを ベースラインパフォーマンス と呼ぶ
  • また、CPUを使用するたびに、CPUの使用権である CPUクレジット が消費される
  • CPUクレジットに余裕があれば、ベースラインパフォーマンスを超えたCPU性能を出せる。これをバーストと呼ぶ
  • T2インスタンスは、低いCPU占有率での運用を想定したサービスなので、高頻度にCPUを専有するならば、別のインスタンスタイプへの移行を検討すべき

CPUクレジット

1CPUクレジット → 1コアのCPUを100%の使用率で1分使用できる権利

  • もし、1分間にCPUを50%占有したならば、0.5CPUクレジット消費される

ベースラインパフォーマンス

CPUクレジットは、ベースラインパフォーマンス を維持できる額だけ、時間単位で補充される

  • 例えば、t2.nano ならば、1Hに3CPUクレジット補充される
  • 3/60min = 0.05 なので、t2.nano で 1Hに使用できるCPU占有率は5%
  • なので、t2.nano のベースラインパフォーマンスは、5%/h

バースト

ベースラインパフォーマンス以下のCPU占有率の間は、CPUクレジットは余る

余ったCPUクレジットがある限り、ベースラインパフォーマンス以上の性能を出すことができる

これを バースト と呼ぶ

  • なお、余剰CPUクレジットは、インスタンスタイプ毎にキャップがある

T2 Unlimited

余剰CPUクレジットがなくなった後も、CPU時間を課金して取得できるサービス

  • 1日分CPUクレジットを前借りできる
  • 前借り分が1日分CPUクレジットを超えた所から、vCPU時間あたり0.05ドル(Windowsでは0.096ドル)で課金される

もし恒常的にCPUを専有するサービスならば、コスパが悪いので別のインスタンスを検討すべき

  • T2 Unlimitedは、一時的なバーストに対応するためのもの

参考

新しいT2 Unlimited – バーストを超え、高い性能を発揮 | Amazon Web Services ブログ

ストレングス・ファインダーをやってみて自分の特性が明確になったお話

先にまとめ

主に自分向けの内容です

  • ストレングス・ファインダーは、得意を伸ばすために、自分の資質と伸ばし方を知るメソッド
  • 自分の資質のTOP5は、「適応性」「回復志向」「調和性」「収集心」「原点思考」だった
  • 自分の方向性が見えたので、今後の行動の指針にすべく「できないこと」「積極的にやること」「強みを伸ばすためにやること」を作ってみた
  • 自己評価が低い人は一度やってみると良いと思った

ストレングス・ファインダーとは

その人の精神的な特性(「資質」と呼ぶ。全32種類)を見える化して、それを伸ばして「強み」にするメソッド

  • 人は苦手をなくすより得意を伸ばしたほうが得るものが多いよね。という思想で作られている
  • 古本を買わないように注意!! 本についてるアクティベーションコードで、資質をチェックするwebテストを受けて、それを元に話を進めるため

自分はどうだったの?

自分の資質のTOP5は、「適応性」「回復志向」「調和性」「収集心」「原点思考」だった

それぞれ、こんな特性だと理解

適応性

現在に重きを置き、柔軟に現在の状況に対処する資質。 弱点は厳密な計画性や手順。計画をたてるときは別の資質を持つ人に助けてもらう。 短期決戦の繰り返しの時に最も生産的になれる。

回復志向

問題の解決が得意。チームやプロジェクトの問題を特定し、本来あるべき状態に回復させる。 自分の問題に厳しく向き合いすぎるので、改善可能な具体的な課題(スキル不足など)に落とし込むと良い。自分が得た経験を共有し、問題の予防に落とし込めればより価値を提供できる存在になれる

調和性

同意点を求め、違いを受け入れる資質。違う視点を持つ人々を交流することができるタイプ。その人達を招き入れたり、頼ることでより多くのものを得ることができるはず。また、ファシリテーター向き。逆に日常的に人と対立する仕事や人が対立している環境は避けるべき

収集心

コレクター。何のためではなく、収集する性質。毎日新しいものごとを収集する必要がある仕事が向いている。意識的に収集する時間を作ると良い。集めたものを役立つようにアウトプットするのが苦手なので、意識して集めたものに価値を見出してくれるグループにアウトプットしていくこと

原点思考

歴史的経緯、はじめの意図を知ることで今の問題を解決できると信じている。ものごとの背景に関する深い理解を示す。その人のこれまでを知っているのでより深く交流ができる。逆に初対面や新しい状況が苦手。過去の事例から、成功の為に切り捨てるべきことと、保持するものが分かるはず

資質を見せられて感じたこと

  • 自分が今まで他者に言われてきたことが大半だったので、納得感は高かった
  • 意思決定や未来を想定するというのがニガテというのは、ちょうどマネジメントに挫折した所だったので納得
  • 相反する資質については、その資質を持つ他者とチームを組むことで生産性を上げれば良い。とも本に書かれているし、せっかく調和性が高いので人に頼ることを意識したい。
  • 調和性は裏目に出ると他者の要望に答えている内に自分の長期的な利益を損なうらしい。自覚があるので、どこまで許容するか自分の中で線を引きたい
  • 長期的な計画を短期決戦に落とし込む工夫をする必要がある。OKRのKeyActionをなるべく細かく具体的にするとか、(当たり前だけれど)スプリントバックログで付けられた優先度で作業するとか、個人的なテクニックとして、ポモドーロ・テクニックとか、TDDとか。

自分の方向性が見えたので、今後の行動の指針にすべく「できないこと」「積極的にやること」「強みを伸ばすためにやること」を作ってみた

それを自覚して他者にも明示することで、より良いアウトプットができるはず

これは本に書かれていることではなく、自分をより俯瞰するために勝手にやってみたこと

できないこと

  • 長期的な計画を立てたり、意思決定をするときは、助けが必要
  • 常に厳密な行動が定められている仕事はミスをする可能性が高い
  • 対立が発生している環境に居続けることはできない

積極的にやること

  • 発生したトラブルや障害について率先して対応する
  • ミーティング等で積極的にファシリテーターを務める

強みを伸ばすためにやること

  • 人に頼る。1日1回だれかにアドバイスや助けを求める
  • トラブルを解決するためのスキルを身につける。月に1つテーマを決めて、現状の仕事で足りていないスキルを身につける
  • 長期的な計画を短期決戦に落とし込む。大きいタスクは切り分けて、自分の中で締め切りを設ける

最後に感想

自分の苦手には目がいくが、得意は自覚できていなかったので、やれて良かった。自己評価が低い人こそやると良いと思った

ECSのawsvpcネットワークモードおぼえがき

awsvpcネットワークモードとは?

taskにENIを紐付けるネットワークモード

ENIとは?

Elastic Network Interface

仮想ネットワークカードを表す VPC 内の論理ネットワーキングコンポーネントです インスタンスにネットワークインターフェイスをアタッチすると、プライベート IP アドレス、Elastic IP アドレス、セキュリティグループを指定できます。

docs.aws.amazon.com

ENIが使えると何が得なの?

ENIを使えば、taskが通信する時にhostのネットワークインターフェースを意識する必要が無くなる

  • ENIを使わない場合 hostマシンのネットワークインターフェースを使う必要がある。その為、複数のtaskが動作するhostのセキュリティは、最大公約数的なものになってしまう

その他の特徴

同じタスクに属するコンテナが、localhost インターフェイス経由で通信できるようになります。 ある時点でタスクに関連付けられている Elastic Network Interface は 1 つだけです。

docs.aws.amazon.com

AWS Fargateの場合、awsvpcネットワークモードが必須

ホストマシンが存在しないので、独自にネットワークインターフェースを持つ必要があるため

AWS Fargateでtaskを動作させるのに必要な設定の記録

task definition

以下はインスタンスのcpuinfoとメモリの情報をチェックするtaskのdefinition

{
    "family": "get_fargate_cpu_info",
    "containerDefinitions": [
        {
            "name": "get_fargate_cpu_info",
            "image": "#{AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/get_fargate_cpu_info",
            "entryPoint": ["bash", "-c", "cat /proc/cpuinfo && free -h"],
            "essential": true,
            "memoryReservation": 512,
            "logConfiguration": {
               "logDriver": "awslogs",
               "options": {
                 "awslogs-group": "get-fargate-cpu-info",
                 "awslogs-region": "us-east-1",
                 "awslogs-stream-prefix": "cpuinfo"
               }
            }
        }
    ],
    "requiresCompatibilities": ["FARGATE"],
    "networkMode": "awsvpc",
    "cpu": "256",
    "memory": "512",
    "executionRoleArn": "arn:aws:iam::#{AWS_ACCOUNT_ID}:role/ecsTaskExecutionRole"
}

aws ecs run-task

{
  "taskDefinition": "get_fargate_cpu_info",
  "cluster": "get-fargate-cpu-info",
  "networkConfiguration": {
    "awsvpcConfiguration": {
      "subnets": ["subnet-********"],
      "securityGroups": ["sg-********"],
      "assignPublicIp": "ENABLED"
    }
  },
  "launchType": "FARGATE"
}
  • launchType : FARGATE 必須
  • networkConfiguration : awsvpcConfiguration の定義が必要
    • assignPublicIp: ENABLED にして、外に出れるようにしないと、ECRからコンテナを取りにいけない

参考