kasei_sanのブログ

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

クイズ形式で 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からコンテナを取りにいけない

参考

AWSのドキュメントに添ってECSを動かしてみた

この2つを参考に、ECSを動かしてみた

docs.aws.amazon.com

docs.aws.amazon.com

ゴール

Hello World と書かれた index.html を持つ apache サーバをECSで動作させて、ブラウザで動作確認する

手順

  1. DockerImageを作る
  2. DockerImageをECRに登録する
  3. Task DefinitionをECSに登録する
  4. Taskを実行するClusterを作成する
  5. Cluster上でTaskを起動する

DockerImageを作る

以下の Dockerfile を作成する

FROM ubuntu:12.04

# Install dependencies
RUN apt-get update -y
RUN apt-get install -y apache2

# Install apache and write hello world message
RUN echo "Hello World!" > /var/www/index.html

# Configure apache
RUN a2enmod rewrite
RUN chown -R www-data:www-data /var/www
ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2

EXPOSE 80

CMD ["/usr/sbin/apache2", "-D",  "FOREGROUND"]

Imageを作成

$ docker build -t hello-world .

動作確認

$ docker run -p 80:80 hello-world

DockerImageをECRに登録する

ECSから使用するImageを参照できるように、レジストリに登録する必要がある

リポジトリの作成

$ aws ecr create-repository --repository-name hello-world

戻り値

{
    "repository": {
        "repositoryUri": "${registryId}.dkr.ecr.us-east-1.amazonaws.com/hello-world",
        "repositoryName": "hello-world",
        "createdAt": 1521868901.0,
        "repositoryArn": "arn:aws:ecr:us-east-1:${registryId}:repository/hello-world",
        "registryId": "${registryId}"
    }
}

Imageにタグをつける

$ docker tag hello-world ${AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/hello-world

タグとは

  • Gitのタグと近い概念
  • Imageに複数のタグが登録できる
  • 7.7 とか 7.7.4-alpine とかバージョンやディストリビューション毎にタグを付けて管理することが多い

上記のコマンドの場合、タグ名を指定していないので、latest タグが付く

タグ名を付けたい場合は、image名の後ろに :TAGNAME を付ける

ECRにImageをpushする

dockerコマンドからECRにログインするためのコマンドを生成させる

$ aws ecr get-login --no-include-email

標準出力に出てきたコマンドを実行して、ECRにログインする

  • ******** はパスワード
$ docker login -u AWS -p ******** https://${AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com

ECRにImageをpushする

$ docker push ${AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/hello-world

Task DefinitionをECSに登録する

Task Definitionを作成

{
    "family": "hello-world",
    "containerDefinitions": [
        {
            "name": "hello-world",
            "image": "${AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/hello-world",
            "cpu": 10,
            "memory": 500,
            "portMappings": [
                {
                    "containerPort": 80,
                    "hostPort": 80
                }
            ],
            "entryPoint": [
                "/usr/sbin/apache2",
                "-D",
                "FOREGROUND"
            ],
            "essential": true
        }
    ]
}

Task DefinitionをECSに登録する

$ aws ecs register-task-definition --cli-input-json file://hello-world-task-def.json

Taskを実行するClusterを作成する

AWSコンソールから作ると色々必要なものを自動で作ってくれるらしい

f:id:kasei_san:20180325174555p:plain

AWS Fargate でも良いが、まずはEC2インスタンスを使ったクラスタを理解したいので「EC2 Linux+ネットワーキング」を選択

f:id:kasei_san:20180325174719p:plain

必要な項目を入力後、Cluster、VPC、サブネット、IAMポリシー、オートスケーリンググループ等、必要なものが自動的に作成された

f:id:kasei_san:20180325175537p:plain

Cluster上でTaskを起動する

aws ecs run-task でタスクを起動できる

$ aws ecs run-task --task-definition hello-world --cluster test

AWSコンソールでTaskが起動していることを確認

f:id:kasei_san:20180325180307p:plain

インスタンスのURLにアクセスすると、Hello World が表示されている!

f:id:kasei_san:20180325180427p:plain

ひとまずここまで

今後理解したいこと

  • Service(今回はタスクしか使わなかった)
  • オートスケーリンググループ
  • ロードバランシング
    • 複数のコンテナで同じタスクを起動した場合、どのようにロードバランシングされるのか?
  • AWS Fargate

Amazon ECS 覚え書き

Amazon ECSとは

Amazon Elastic Container Service (Amazon ECS)

Docker コンテナをサポートする拡張性とパフォーマンスに優れたコンテナオーケストレーションサービスです

  • (最近乱立しがちでK8Sに統合が向かうのかどうなのかわからない)コンテナオーケストレーションサービスの一つ。
  • API/web画面から、EC2クラスタ上にDockerコンテナを起動/管理できる
  • AWS Fargate を使えば、インフラ(EC2)のことを考えずにコンテナを管理できる

用語

Task

1つ以上の協調して動作するコンテナ群

  • Dockerでは、1コンテナ1サービスを推奨しているので、何かを実現しようとすると大体複数のコンテナが必要になってくる

Task Definition

Taskの設定

  • docker-composeとかと近い概念

Service

  • タスクで必要なコンテナを指定した数だけ起動/維持してくれる
  • なんらかの理由でタスクが死んでも、サービスは必要数のタスクを維持する
  • あとELBとの連携とか

Cluster

Taskを実行するEC2の集合

  • 各EC2インスタンスには、ecs-agent なるサービスが起動していて、ECSとやり取りしている

参考

Amazon EC2 Container Service(ECS)のデータモデルについて整理した | Developers.IO