Edited at

YAPC::Asia 2015 聴講メモ: 2日目版

More than 3 years have passed since last update.


全体的なまとめ

「3分でサービスのOSを入れ替える技術」が自分にとってのベストトークだった。

アーキテクチャは変えず、飛び道具に頼らず自動化を進めていく話だったのがよかった。


11:00 我々はどのように冗長化を失敗したのか (30 分)

立ち見だったのでメモなし


11:40 Docker3兄弟について (30 分)

立ち見だったのでメモなし


3分でサービスのOSを入れ替える技術


  • 3ヶ月でスケールアウトできるように

  • ゴールデンイメージをもとに手順書ベースの作業。4-6時間ぐらいの刺し身タンポポ作業


    • スケールしない



  • Puppetの導入


    • Scientific Linuxの採用が火を吹いた


      • 構築当時はCentOSの動向があれだったのでSLにした



    • 壊れていた設定ファイル、マニフェストを修正

    • Master/Agent方式を採用

    • 結果としてゴールデンイメージが不要に



  • 自動化


    • OS起動からサービスインまでを自動化した

    • SSHしないで済むように考えた

    • SSHしないとは


      • インスタンス=プロセス

      • プロセスにアタッチして中身を見ることはあまりない

      • プロセスが持っているメモリを外から書き換えたりすることもない



    • cloud^init


      • 起動時に初期化の処理を実行するしくみ

      • ドキュメントが非常にすくない

      • OSの設定だけにとどめて、コマンド実行はPuppetでやるようにした



    • ホスト名、IPからの分離


      • IaaSのAPIで代替する



    • Rails


      • Rails3からRails4にアップグレード



    • まとめ


      • アーキテクチャ自体は変えない

      • 現状の運用を把握して、自動化できるタスクを自動化する





  • 高速な自動化


    • Capistrano3へのアップグレード

    • Rails bundle


      • bundle, bowerやアセットコンパイルなどをすべて実行したものをバッケージしてアップロードする

      • S3にアップロード、各ホストはS3からパッケージを取得して展開



    • Consul


      • Nagiosの運用が難しかったのでConsulを検討

      • プロセス監視にConsul, Consul-alertを使った



    • Mackerel


      • Muninは台数が決まっていれば運用しやすいが、オートスケールに向いていない

      • シャットダウン時の退役は公式でサポートされた



    • Fluentd


      • サーバーが増えてもバックアップで困らないようにFluentdで集約



    • Thor


      • コマンドラインツールを作るのに便利なGem

      • 自動化したもろもろの処理をコマンド一発で使えるように実装





  • 圧倒的に高速化


    • 重い処理をフェーズでわけてイメージを作る

    • Packer


      • インスタンスの属性を指定。JSONで定義

      • cloud-initとProvisionerが使える

      • Packerで構築したイメージをServerspecでテスト

      • Thorでコマンド化





  • Blue-Green Deployment


    • 自動化の設計がしっかりできていればわりとできる

    • AWSを使っているならELBでやる

    • AWSを使っていない場合はNginxやConsul, Consul-templateを使うなど




辛いことをやめる!から始まる業務改善とInfrastructure as Code


  • 時代遅れがつらくなる


    • 物理サーバーのやりかたが通じなくなった

    • 手順書作業の限界

    • 忙殺されると新技術のキャッチアップに手が回らなくなる



  • 改善する


    • しかし、今までのやりかたを変えるのは大変なこと

    • 安定したやりかたを変えなくては行けない

    • やり方を変えるならメリットを明確に提示する



  • 問題の理解


    • 現状の問題とあるべき姿のギャップと捉える

    • すべての問題を洗い出すのは不可能に近い

    • 経営理念、社訓と見比べてみるといいかも

    • 何度も繰り返す小さな作業


      • 自動化がしていない



    • 長い時間が必要な作業


      • 情報共有の問題





  • 難易度とコストで優先度を考える

  • OSSを使わない理由


    • クライアントによって環境が異なる。一般化が難しい。要求も異なる



  • どう進めるか


    • 技術責任者のサポートを得る

    • メリットを伝える。何が改善できるのか、何のためにやるのか

    • うまくいってない予兆を感じたらすぐにサポートする。放置されたプロダクトは使われなくなっていく

    • ドキュメントを書いて伝える


      • TIPSもふくめておく



    • ハンズオンデモをする。スケジュールが合わないひとのことも考えて何度かやる



  • 評価する


    • 時間や金額で、改善したことがどれぐらいの価値を出しているかをわかるようにする



  • プログラミングを運用に持ち込むことでさらに効率化が進む