Search on the blog

2017年7月19日水曜日

[Blog Reading] Hiring SREs at LinkedIn

 SREの採用プロセスに関する話。SREに限らずエンジニアの採用プロセスについてのいい話が書いてある。

https://engineering.linkedin.com/blog/2017/07/hiring-sres-at-linkedin

  • 人を雇いたいときは、その人に満たしてほしい特定のニーズがある
    • その特定のニーズを満たすために必要なスキルはなにか
    • 採用試験ではそのスキルだけをテストする
  • まず電話・オンラインで試験をする(スケールしやすい)
    • オンサイトでの試験は受験者/採用者ともにコストがかかる
  • 複数回のオンライン試験をパスした有望な求職者のみをオンサイト試験に招待する
    • オンサイト試験ではオンライン試験でやらなかったことをやる

2017年7月10日月曜日

Nat Gatewayが意外と高かった

最近AWSでネットワークの勉強をしているのだけど、請求書を見てみたら予想外にコストがかかっていた。

EC2は都度停止しているはずなのに何故かなと思って明細を見ていたら、Nat Gatewayだった。

1時間あたりのコストがt2.microインスタンスの4倍近くかかるらしい。VPC自体は無料で作れるので、NATも無料だろうと思って油断していた。


(追記)
マネージドなNATがなかった頃は、EC2インスタンスを立ててNAT用のマシンにしていたらしい。NATが落ちるとprivate networkのマシンからインターネットが見れなくなるので冗長化したり、パフォーマンスを考えてそこそこいいEC2を使ったりしないといけなかったらしく、それを考えると妥当な値段だということが分かった。
ただし、個人で学習用に使う場合はやはり高いので、動作確認ができたらさっさと削除しましょう。

2017年7月9日日曜日

並行と並列の違い

並行(concurrent)処理とは、複数のタスクを非同期で同時に実行すること。
並列(parallel)処理とは、複数のCPUを使って複数のタスクを同時に実行すること。

つまり、並行の方が広い概念で、並列処理は並行処理の一種。

並行処理にはいくつかの実現方法が考えられるが、複数のCPUを使って物理的に同時に複数の命令を走らせているものを並列処理と呼ぶ。

ということで、場面によって使い分けた方がいいかもしれない。

  • 複数のサーバを立てて並列処理をする
  • マルチコアCPUで並列処理をする
  • シングルコアマシン上でマルチスレッドを使って並行処理をする
  • コルーチンで並行処理をする
並行の方が広い概念なので、並行処理と言っておけば間違いは少なそうだが、物理的に同時に実行するということを強調したい場合は並列と言った方がいいかもしれない。

並列処理

並列ではない並行処理


2017年7月6日木曜日

[Blog Reading] Neflix Platform Engineering — we’re just getting started

 エンジニアリングの世界に終わりはない、常に新しいチャレンジが待っているという内容のブログ。


  • 2, 3年ほど前にKafkaを使うようになった
  • 最近はApache Flinkをストリーム処理に使うようになった
  • AMI/VMからcontainer technologyに移行
  • 数100のマイクロサービスが動いている
  • Chaos Monkey(NetflixのOSS)からChaos Engineeringという規範が生まれた

2017年6月27日火曜日

[Blog Reading] Building a Real-Time Streaming ETL Pipeline in 20 Minutes

Confluentのブログを読んだ。
最近KafkaまわりのOSSにプルリク送ってみたりして、Confluent熱が個人的に高まっている。

Building a Real-Time Streaming ETL Pipeline in 20 Minutes

以下、感想・考えてみたことなど。

  • Kafkaってなんなのか一言で説明するのは難しいが、このブログにあるように「分散ストリーミング基盤」というのが良さそう。
  • Streaming ETLという概念がやばい。Batch ETLでやっているような集計処理をバックグラウンドでリアルタイムに実行できるやつ。
    • ブログの下の方で引用されているが、簡単なサンプルアプリがあるので見てみるとイメージがわく
  • 「複数のアプリが同じデータソースを参照していると密結合になる」みたいな話を聞いたことがあったが、その感覚が分かった。例えば、アプリAがデータ生成するテーブルAがあったとして、これをみたい他のアプリB, C, D, ..があったとする。アプリB, C, D, ..からテーブルAを直接参照すると以下のような問題が起こる。
    • 参照者が増えてくると、テーブルAのアクセス負荷が増える(Producer:Consumer = 1:N)
    • アプリAが自由にテーブルAのスキーマを変更できない(テーブルAの変更は参照側のアプリに影響を与える)
    • 参照で集計処理をしたい場合は、日次バッチになってしまう(負荷が高いのでリアルタイムで集計できない)

2017年6月24日土曜日

VagrantのゲストOS間でホスト名参照

 Vagrantfileでホスト名を指定してるのに何故か参照できなかった。

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu15.04"
  config.ssh.insert_key = false
  config.vm.define "kafka-base" do |server|
    server.vm.network "private_network", ip: "192.168.33.11"
    server.vm.hostname = "kafka-base"
  end
  config.vm.define "kafka-connector" do |server|
    server.vm.network "private_network", ip: "192.168.33.12"
    server.vm.hostname = "kafka-connector"
  end
end

vagrant@kafka-base:~$ hostname
kafka-base
vagrant@kafka-base:~$ ping kafka-connector
ping: unknown host kafka-connector
vagrant@kafka-base:~$ cat /etc/hosts
127.0.0.1 kafka-base  kafka-base
127.0.0.1 localhost
127.0.1.1 vagrant-ubuntu-trusty.vagrantup.com vagrant-ubuntu-trusty
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

vagrant-hostsというプラグインを入れてみると解決した。
$ vagrant plugin install vagrant-hosts

以下のようにserver.vm.provisionの行を追加すると、ホスト名が設定され、さらにゲストOSの/etc/hostsに仮想マシンのホスト名情報が追記される。
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu15.04"
  config.ssh.insert_key = false

  config.vm.define "kafka-base" do |server|
    server.vm.network "private_network", ip: "192.168.33.11"
    server.vm.provision :hosts, :sync_hosts => true
  end
  config.vm.define "kafka-connector" do |server|
    server.vm.network "private_network", ip: "192.168.33.12"
    server.vm.provision :hosts, :sync_hosts => true
  end
end

以下のように動作確認してみると、ホスト 名でゲストOS間の通信ができることが分かる。
vagrant@kafka-base:~$ hostname
kafka-base
vagrant@kafka-base:~$ ping kafka-connector
PING kafka-connector (192.168.33.12) 56(84) bytes of data.
64 bytes from kafka-connector (192.168.33.12): icmp_seq=1 ttl=64 time=0.470 ms
64 bytes from kafka-connector (192.168.33.12): icmp_seq=2 ttl=64 time=0.348 ms
^C
--- kafka-connector ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.348/0.409/0.470/0.061 ms
vagrant@kafka-base:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 kafka-base
192.168.33.11 kafka-base
192.168.33.12 kafka-connector

Vagrantで共通のssh private keyを使う

 Vagrantで複数の仮想マシンを立ち上げて、仮想マシン間でsshの秘密鍵を共有したい場合がある。Vagrant 1.8でのデフォルトの設定ではマシンごとに異なる秘密鍵が生成される。

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu15.04"
  config.vm.define "kafka-base" do |server|
    server.vm.network "private_network", ip: "192.168.33.11"
  end
  config.vm.define "kafka-connector" do |server|
    server.vm.network "private_network", ip: "192.168.33.12"
  end
end

秘密鍵情報を確認。仮想マシンごとに別の秘密鍵が生成されていることが分かる。
$ vagrant ssh-config
Host kafka-base
  HostName 127.0.0.1
  User vagrant
  Port 2200
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/kenjih/work/vagrant_ansible_kafka/vagrant/.vagrant/machines/kafka-base/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL

Host kafka-connector
  HostName 127.0.0.1
  User vagrant
  Port 2201
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/kenjih/work/vagrant_ansible_kafka/vagrant/.vagrant/machines/kafka-connector/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL

 しかし、デプロイ自動化を行う場合など、共通の秘密鍵を使えると便利なことが多い。そのような場合は以下のようにconfig.ssh.insert_key = falseという設定を追加すればよい。

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu15.04"
  config.ssh.insert_key = false
  config.vm.define "kafka-base" do |server|
    server.vm.network "private_network", ip: "192.168.33.11"
  end
  config.vm.define "kafka-connector" do |server|
    server.vm.network "private_network", ip: "192.168.33.12"
  end
end

秘密鍵情報を確認してみると、共通の秘密鍵を利用できることが分かる。
kenjih$ vagrant ssh-config
Host kafka-base
  HostName 127.0.0.1
  User vagrant
  Port 2200
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/kenjih/.vagrant.d/insecure_private_key
  IdentitiesOnly yes
  LogLevel FATAL

Host kafka-connector
  HostName 127.0.0.1
  User vagrant
  Port 2201
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/kenjih/.vagrant.d/insecure_private_key
  IdentitiesOnly yes
  LogLevel FATAL