Recruit Technologies Open Lab #03 テーマ:Infrastructure as Code メモ

昨日行ってきました。
内容に単純に興味があったのと、著名な方々が来ていて今まで一回も生でお目にかかったことがないなぁと思ったので参加してみました。
Twitterで見つけてすぐに応募しましたが、すでに200人越えてて補欠枠だったのですが、前日に繰り上がりになって良かったです。

https://atnd.org/events/78581
動画 が上がっています。僕も週末見てみます。


“Infrastructure as Code” から数年、結果どうなったか

伊藤 直也 (一休.com CTO)

Infrastructure as Code が世の中に出てきて

元はCFEngineが1993年に出てきてからPuppet, Chef, Ansibleが出てきた
2011年にAWS東京リージョンが来た。
2013年「入門Chef Solo」が出版された。

クラウドになってきてから Infrastructure as Code が広まっていった。

当時に期待値は秘伝のタレをソース化
=> コードにしてみたらGitでバージョン管理、GitHubでPRなどインフラもコードを書く
=> テスト(Serverspec)、CIもできる
=> GitHubでマージボタンを押せば自動的に適用される

本当の目的は自動化やコード化を達成したいからではなかった。
Configuration as Code

サーバ以外にも応用できないか?

  • Route53の設定を宣言的に定義&適用する
  • DNS設定をGitHubで管理、masterにマージするとDNSが反映される
    => 変更反映をGitHubのマージボタンに集約される
    => 権限管理が課題

  • ビルドの再現可能性が重要

    • 何回やっても同じ結果(冪等性)
      => Configuration as Code
  • Terraform

  • Docker Compose

ソフトウェア開発のプラクティスをインフラにも適用する。

インフラストラクチャをモデリング

  • モデリングすることで複雑性を取り払い本質を捉える
  • 業務をそのままシステムに落とすのではなく、モデリングすることで業務に活かすことができる(DDD)

  • 自動化やCI/CDをやる前にモデリングをやるべきなのではないか

Ansible vs Chef

  • どちらがより、現システムのモデリング要求基準に適しているか
    => これは他のツールにも言えるのではないか

モデリングは今後広まっていくか

  • 今のところ期待値はあまり高くなさそう

[感想]
Chefを導入するときに「入門Chef Solo」には大変になった。その頃から Infrastructure as Code という単語をよく耳にするようになって本当の目的を見ていたわけでもなく、ただサーバ構築を自動化したい、(当時最先端だった)Chefを使ってみたいという欲求でしかなった。
話していた内容で印象的にだったのが「Cookbookとか作ったとしても数年後にそれが技術的負債になるかもしれない」で、確かに構築するサーバはどんどん増えていくし、変更箇所も増えていったり変わっていったりあっという間にソフトウェア以上に負債を抱え込んでしまう可能性があって、自動化がゴールにするのではなくてその先(モデリング)にまで目を向けて考えなければならないなと思った。DDDは挫折したから再挑戦しようかな。


Infrastructure as Code と企業文化

吉羽 龍太郎 (ryuzee.com)

http://slide.meguro.ryuzee.com/slides/75

よくある文化的な問題

  • ソフトウェア開発のベストプラクティスが導入できない

Infrastructure as Code

  • サーバ内だけにとどまらず、サービスを動かすインフラ全体が対象になる
    • DNS, Network etc
  • インフラとアプリとの境界がなくなっていく

コンウェイの法則

  • 企業文化・体質がシステム・ソフトウェアに体現される法則
  • 逆に言えばシステム・ソフトウェアの品質を上げたい場合は組織構造を変える必要がある

組織構造

(1)インフラ部(部署・サービス部門と、インフラ部)

  • 全社横断型インフラ部
  • インフラ部がボトルネックになる。インフラ部で定めたSLAになってしまう
  • 均質化がすすむのでアプリ側の要件を満たせない
  • Cookbookなどを作って標準化を図ろうとしても部署ごとに要件が異なるので結局破綻する

責任分界点問題

  • AWSなどクラウド上だとインフラとアプリ側の境界が難しくなる
  • 例) Auto Scalingの設定、AMI作成はどっち側なのか
  • 急な変更が必要なときにどうするのか

  • 境界は曖昧。つなぎ方がアーキテクチャ

(2)部門ごとにインフラチームがいる

  • インフラが複数プロジェクトを兼任したばあい、インフラチームではなく個人に負荷が偏ってしまう
  • インフラ部門での情報やベストプラクティスの共有が必要になる
  • 変化に対応し続けられる

(3)製品単位でチームを作り、その中にインフラエンジニアを含める

  • サービスをゴールにできるので集中しやすい
  • 一番変化に強くなる
  • インフラ専任とは限らない。アプリ開発者のなかでインフラもできるエンジニアが担当することもある
    • スキルをまとめたマトリックスを利用する
  • 他の製品チームを意識しない => 全製品をまたいだ一貫性は担保されない
  • 認証・セキュリティ等の要求基準を合わせるコントロールが必要

(3-1) (3)に加え、チームを跨いだセキュリティ/標準化チームを設ける

  • セキュリティ設定済のイメージ、Terraformスクリプト、各種ガイドラインなど標準化がすすむ
  • チームの自立性+外部からの最低限守るべきルールの提供
  • Amazon, Netflixなどがこの形をとっている

責任範囲マトリクス

  • 各レイヤー、タスクについてアプリエンジニア、インフラエンジニアなどどこに責任があるのかを見える化する

文化面でのチャレンジ

  • やりたいことに沿った組織構造が必要
    • 上の人に言う覚悟
  • いきなりやろうとすると抵抗を受ける
    • 最初は小さくやって事例をつくる
    • 最初に失敗すると二回目以降やるのが難しくなる
  • 人間系が泥臭い

[感想]
組織構造がソフトウェアの品質に現れるコンウェイの法則は初めて知った。インフラだけをやる人はよりよいソフトウェアを作る上で要らない存在になっていくようで危機感を抱く。


Infrastructure as Code のこれまでとこれから

宮下 剛輔 (Recruit Technologies ATL 技術顧問)
合同会社Serverspec Operations代表

Infrastructure as Code の三本柱

  • 自動化
  • バージョン管理
  • テスト

最近の Infrastructure as Code 事情

オライリー「Infrastructure as Code」

Dynamic Infrastructure Platforms

  • IaaS etc

Infrastructure Definition Tools

  • Terraform, CloudFormation etc

Server Configuration Tools

  • Chef, Puppet, Ansible etc

Infrastructure Services

  • オーケストレーション部分
  • モニタリング etc

Infrastructure as Code が対象とする領域
=> Infrastructure Definition Tools, Server Configuration Tools

Infrastructure as Code のこれから

  • 対象領域が広がり、より複雑化していく
  • 出来る限りシンプルに実現していく必要がある
  • 学術系的アプローチ
    • グラフ理論、ディープラーニング
  • テスト分野はまだ未成熟(改善の余地が十分ある)
  • モニタリングとの融合
    • 本番デプロイ後

影響を与える要素

Dynamic Infrastructure Platforms

  • マルチクラウド対応、ベンダーロックイン回避

Container

  • Infrastructure Definition Tools, Infrastructure Services の重要性が増大
  • Server Configuration Tools の重要性が低下
    • Serverspec でテストすれば良い
  • サーバ管理というよりプロセス管理

Microservices

  • システムは複雑化しているが、コンポーネントは単純化

Infrastructure Services

  • Infrastructure as Code の恩恵が不十分
  • 動的な振舞いを記述する
    • Server Configuration Tools は静的な状態を記述していた
  • 自律制御も重要になってくる
  • 動的平衡
  • ソフトウェア開発との境界が薄くなってきている(曖昧になってきている)
    • あまり縁がなかった手法の応用
      • 形式手法の設計
      • Consumer-Driven Contract Testing

[感想]
Infrastructure as Code について掘り下げて過去・現在・未来についてのお話。アプリケーションとインフラの境界が薄れてきている中でソフトウェア開発で取り込まれてきたベストプラクティスをインフラにも適用していく時代になった。今までほぼ1人で開発・運用してきたからチームでの開発やそのノウハウなど分からないけれども今後必要になるのだろう。


運用・監視もコード化する。開発者が監視まで考える方法論

松木 雅幸(id:Songmu) (株式会社はてな)

http://songmu.github.io/slides/recruit-technologies-open-lab-3/#0

モニタリングの重要性向上

  • オライリー マイクロサービスアーキテクチャ

  • 監視とは継続的なテストである

  • 監視とは健康診断である
    • 結果を見てもわかる数値と分からない数値がある
    • 分かる数値から追いかけていく
  • 難しくない範囲で監視する

何を監視すれば良いのかを考える

  • メトリックを取得可能にする
    • 監視ための内部的APIを作る
  • コード化する

    • 監視プラグインは単なるコマンド実行
    • チェック監視
      • OK/NG
    • メトリック監視
      • 数値データを可視化
  • mackerel-plugin-gostat
    • Go製監視プラグイン

監視設計

  • 何を監視するかを考える
  • 監視できるようにする

閾値設定をコード化する

  • mkr monitors
  • 監視設定をJSONで取得

  • 監視設定をリポジトリ管理してCIで自動反映

アラートに対するアクション

  • Mackerel のアラート通知はWebhookで受け取ることができる
  • fluent-plugin-webhook-mackerel
    • fluentdでwebhookを受け取れる

サーバ管理

  • Mackerel は当初サーバ管理的な思想が強かった
  • はてなではアプリケーションサーバ一覧をMackerelから取り出してデプロイしている

[感想]
前半は監視全般、後半はmackerelのお話。MackerelでMacの熱の温度をモニタリングをしているのは少し面白かった。これから社内でmackerelを導入していくけど、ただモニタリング・監視するだけではなくてもっと色々なことができそう。


プロビジョニングツールはMakeで決まりだろ

大谷 和紀 (VOYAGE GROUP)

  • 途中で失敗(0以外を返す)とmakeが失敗する(安全に倒す)

  • プロビジョニングツール

    • 冪等性なんてなかった
      • パッケージインストール適用後、記述を消すとその前に適用したパッケージが残ったままになる
    • 宣言的記述なんてできるのか
  • 昔は共有サーバ(複雑なサーバ)をどう管理するか

  • 今は単機能なサーバをどう組み合わせるか
  • クラウド/コンテナ => 破棄可能なインフラ
    • 状態管理からの脱出
  • サーバレスアーキテクチャになってきた
    • cli, shell scriptとの親和性が良い

[感想]
Makefileを作ったことが無い自分にとって別次元な話だった。

[AWS]スケジュールドリザーブドインスタンスがリリースされた

日次や週次、月次などずっとは稼働させないけれど、定期的に実行するEC2インスタンスに対してリザーブドインスタンスが買えるようになったとのことです。一日数時間しか動かさないEC2インスタンスでもオンデマンドよりも概ね5〜10%ぐらい安くなるとのこと。

ソース
* 公式ブログ
* 日本語版
* ドキュメント

良さそうなだなと思いましたが、欠点がいくつかありそうです。

  1. 従来のRI(スタンダードリザーブドインスタンスというらしい)のように自動的に適用されるのではなく、新たにEC2インスタンスを起動しないとRIが適用されない
  2. スケジュールされた時間が過ぎたEC2インスタンスは強制的にTerminateされる。Stopやリブートもできない
  3. ドキュメントに書いてないけど、スタンダードリザーブドインスタンスのように、インスタンスタイプファミリー内でのインスタンスタイプの変更やスケジュールの変更ができないかもしれない

使い方としては、パッと思いついたのはこんな感じでしょうか。

  • スケジュールされた時間になったら、APIつかってEC2インスタンスをAMIから起動する
  • Terminateされる前に、AMI取る(その後、Terminateされる)
  • 次回起動するときは、先ほど取ったAMIから起動する
  • 以下、繰り返し…

AMIからの起動なのでサーバの状態が変わる度にAMI作る必要があるし、ずっと作るとAMIが増えていくのでローテートしないといけないのが面倒です。

リリースされたばかりでどうなるかわからないけど、まだまだ使い勝手が悪そうなので確実に使えそうなサーバにだけRIを購入するのが良いかと思います。
まだ、東京リージョンには来ていないので焦らないで他の方の知見を待ちましょうw

FluentdからAmazon Elasticsearch Serviceへログ転送する時の注意点

昨年10月にAmazon Elasticsearch Service(Amazon ES)がリリースされました。
今まではEC2インスタンスにElasticsearch をインストールして運用していましたが、AWS側でマネージドしてくれるということでとても便利そうだなと思い使ってみました。

動作環境は以下の通りです。

  • Fluentd 0.10.58
  • fluent-plugin-elasticsearch 0.9.0
  • Amazon Elasticsearch Service r3.xlarge

構成としては、各WebサーバからApacheのアクセスログをFleuntdサーバに集約してAmazon ESへ転送するようにしていました。
しかし、FluentdからAmazon ESへ転送する際に途中でエラーが出てしまい、転送できなくなることがありました。

Fluentd側の設定(一部抜粋)

最初からエラーが出るわけではなく途中でエラーが出てしまい、最終的にはqueue size exceeds limitとなってログを破棄されてしまいました。
Amazon ES側のログが見れないので何故発生したかはこの時点ではわかりません(CloudWatch Logsで見れるようにしてほしいです)。

エラー内容でググると以下のスレッドがヒットしました。

続きを読む

EC2のAutoRecoveryについて調べてみた

サーバを何十台も稼働させているとEC2インスタンスが突然落ちることも少なからず起こってきます。
突然落ちる原因の1つとして「Status Checked Failed」になることがあります。こうなった場合はEC2インスタンスを再起動しなければなりません。自動化するのも少々面倒です。

そこで、昨年リリースされた機能ですが、Auto Recoveryというのがあったので簡単ですが調べてみました。

続きを読む

2015年振り返り&2016年抱負

あけましておめでとうございます。
昨年末に振り返り記事を投稿しようと思いつつ、ダラダラ過ごしていたらいつの間にか仕事始めになってしまいました。
そんなわけで、昨年挙げた抱負を元に振り返り(反省)をしていきます。

仕事

2月に転職しました。
何社か面談させてもらってその内の1社が新卒の頃から知っている会社なんですが、AWSを(チョット)使えるということで気がつけば(IT)インフラエンジニアとして入社していました。
前職で開発をやりつつも、AWSをベースにインフラを担当していたので、さらにインフラのスキルを伸ばしたい!と思ったので経験の無いインフラエンジニアという道を選びましたが、入社してからはかなり大変でした(今も大変ですが)。
先輩エンジニアはとても優秀でチョットできる程度の自分はかなり自信を失いました。また、改めてRDBMSやLinuxといった基礎的な知識が欠けているのでシステムに問題があったときでも対応ができず(今もですが)、なぜこの道を選んだのか自問自答していました。
最近はまだまだ未熟ではあるものの、自分の役割を見出してきたかなと思うので今年は飛躍できるようにしたいです。

家庭

悩ましい1年でした。
詳細は端折りますが、子供が欲しいと思いつつもなかなか上手くいかなかったです。今年は上手くいけるように祈りたいです。

体調

太りました。。。
昨年末が71kgだったのに現在77kgでかなり太りました。
健康診断もいくつか引っかかるようになって危機感が出てきたので毎月1kg減します。
近所に(ほぼ水に近い)温水プールがあるので冬の間は泳いで、暖かくなってきたら学生の頃にやっていた弓道を再開します。

技術的なこと

進歩あったのか・・・?
転職したことでAWSはもちろん、色々なことをやらせてもらってできることは増えましたが、2014年の延長線上で技術的に向上した印象なので今年はもっと向上させたいです。
勉強会も思った程参加できていないし、インプットもアウトプットも弱かったです。2週間に1冊のペースで本を読むと昨年書きましたが全然達成できませんでした。英語も不勉強です。

今年こそは昨年のリベンジをします。
まずは本を読むということで毎週日曜日の午前中はカフェで読む時間を作りましたので継続します。
習慣が継続できたらイベント作って有志で読書会(もくもく読書会的な)をしたいです。

その他

今年は生まれて初めて大吉を連続で引きました。大吉を引いたのも数年ぶりなのに連続で引いたは初めてです。
今年は運が良いと思うので運を見方にして良い年にしたいです。

Icingaのアラート通知の停止忘れを知らせるスクリプトを書いた

Icinga Web REST API を使ってみたで監視ツールであるIcingaをAPIで操作する方法を紹介しました。
また、HubotでIcingaのアラート通知をon/offするCoffeeScriptを書いたでSlack(Hubot)から簡単にアラート通知をon/offできるようにしました。

気軽にIcingaを操作できるようになった反面、設定ミスや設定漏れに注意しなければならないことがあります。特にアラート通知をoffにしたままだとサーバに異変が起こっても通知してくれないので発見が遅れる可能性があります。
そこで、アラート通知がoffになっていることをリマインドしてくれるスクリプトを書きました。

Gistにあげています。

コメントに書いていますが、jqコマンドを使っているのでYumでjqをインストールしておいてください。

このスクリプトを一日に3〜4回 cron等で実行すれば十分だと思います。

HubotでIcingaのアラート通知をon/offするCoffeeScriptを書いた

Icinga Web REST API を使ってみたで監視ツールであるIcingaをAPIで操作する方法を紹介しました。

その活用方法の1つしてHubotと連携してアラート通知をon/offできるようにしてみました。
スクリプトはGistにあげています。

設定や使い方はコメント部分を見てもらえればわかると思います。
<host>は複数ホストを指定できます。

例)

Slackと連携すれば、Slack上でIcingaのアラート通知をon/offすることができるのでとても楽です。

Windows Server のAmazon EC2 リザーブドインスタンスを購入するときに注意すること

小ネタです。

インスタンスタイプが大きいAmazon EC2インスタンスをずっと起動すると料金がかなり高くなってしまうため、リザーブドインスタンスを購入して費用を抑えることがあると思います。

リザーブドインスタンスを購入するメリットの1つに、「リザーブドインスタンスをインスタンスファミリー内の別インスタンスタイプに変更できる」があります。
例えば、c3.2xlarge のリザーブドインスタンスを1台購入した場合、c3.xlarge のリザーブドインスタンス2台に分けることができますし、逆もまた然りです。
なので、リザーブドインスタンスを購入した後、対象EC2インスタンスを使わなくなったとしても別EC2インスタンスに割り当てることができます。

しかし、注意しなければならないのが別インスタンスタイプに変更できるのが「Linux/UNIX」のリザーブドインスタンスのみということです。
Windows Serverの場合、変更できるのがAZとネットワークプラットフォーム(VPC内かそうでないか)のみで、インスタンスタイプを変更することができません。

誤って別のインスタンスタイプのWindows Server リザーブドインスタンスを購入したり、途中で使わなくなった場合は損することになるので購入には十分気をつけた方が良いです。

公式にもちゃんと書いてありました。

すべての製品プラットフォームタイプで、アベイラビリティーゾーンやネットワークプラットフォームを変更することができます。インスタンスタイプの変更は、Linux プラットフォームタイプのみでサポートされています。ただし、ライセンスが異なるため、Linux リザーブドインスタンスから RedHat リザーブドインスタンスまたは SUSE Linux リザーブドインスタンスに変更することはできません。RedHat または SUSE の料金の詳細については、Amazon EC2 リザーブドインスタンスの料金を参照してください。

リザーブドインスタンスの変更

Windows ServerもLinux/UNIXと同じようにインスタンスタイプを変更できるようにしてほしいですね。

複数サーバで同時操作したい時の方法まとめ

今日も飽きずに過去のメモを掘り起こして記事にしました


全台、もしくは一部のサーバに対して一斉にコマンド実行したい場合があります。
調べてみると色々な方法があるみたいなので、いくつか紹介します。
他にあれば随時追加するかも。

tmux

ローカルPCにtmuxをインストールし、~/.tmux.conf に以下の設定を追加します。

同じWindowに複数paneを開いてそれぞれ複数サーバにSSHログインし、<bind>+eすると、paneで操作を同期することができます。
<bind>+Eで同期が終了します。

メリット

  • SSHのパスフレーズやsudoのパスワードなどを考えなくて済む(自分で入力するため)
  • いつも自分がやっている作業をそのままできる、余計なコマンドを覚えなくても済む

デメリット

  • 複数panelを立ち上げてそれぞれサーバにログインするのが面倒
  • panel同期後、コマンド補完ができなかったりするため、予め実行するコマンドをまとめておいて、コピペして実行した方が良い

参考URL

pdsh(Parallel Distributed Shell)

https://code.google.com/p/pdsh/

インストール

基本的な使い方

sudo を使う場合そのままでは渡せないので、次のように強制的にttyを飛ばすようにします。

sudo権限で/rootをlsコマンドで見るようにしてみました。$HOME/.ssh/PASSからsudoパスワードを読み込むことでヒストリに残さないようにしています。dshbakコマンドを使うことで出力を見やすくできるのでよく使っています。

メリット

  • ホスト指定が正規表現で指定ができる

デメリット

  • パスフレーズ付き秘密鍵だと実行できない

pssh(pararell-ssh)

https://code.google.com/p/parallel-ssh/

インストール

使い方

複数ホストを実行したい場合は、--host(-H)オプションを複数付けてもできるが、ホスト一覧のファイルを用意して-hオプションで指定した方が楽です。

しかし、パスフレーズ付きの秘密鍵の場合、パスワードの入力が求められます。
解決するには、苦し紛れですがソースを改変します。

--askオプションを付けるとパスワードを聞かれるのでそれに返すとコマンドを実行できます。
Stderrが出ていて気持ち悪いが気にしないことにします。

sudoを使う場合は -x 'tt' で強制的にttyを飛ばすようにすれば良いです。

メリット

  • (ソース改変が必要だが)--askオプションでパスフレーズ付きの秘密鍵でも実行できる

デメリット

  • Stderrが出てくるので気持ち悪い

最後に

ここまで書いてふと思ったのがAnsibleでもできるかなと思いました。
良い方法があれば教えてください。

MySQLをアップデートしたらエラーになったのでmysql_upgradeで直した

今日も飽きずに過去のメモを掘り起こして記事にしようのコーナーです。
メモが色々なところに分散しているので記事にすることで1つにできるのが良いですね。


MySQLをyumでインストールしており、yum update mysqlしたらMySQLのログにエラー出ていました。

ググったら MySQLが繋がらなくなってたので対応した | Shimabox Blog がヒットしました。
mysql_upgradeコマンドを実行すれば良いみたいです。

念のため、MySQLを再起動して完了です。