portal shit!

GW 中、十分インスタンスを用意しておいたが想定を超えるアクセスがあって負荷が高まり、 Alert が飛んでくる事態となった。車を運転中に iPhone をカーステにつないでいたところ Slack がピコピコ鳴り、嫁さんから「休みなのか仕事なのかハッキリしろ！」と言われたので Alert が上がらないようにオートスケールを仕込むことにした。 いみゅーたぶるいんふらすとらくちゃー諸兄からしたら「そんなの常識じゃん」みたいな話ばかりだけど、自分でやってみて得られた知見をまとめておきます。

なおここで言っているのは EC2 インスタンスのオートスケール（ EC2 Auto Scaling ）であり、 AWS の様々なリソースを包括的にオートスケールする AWS Auto Scaling とは異なります。

Amazon EC2 Auto Scaling（需要に合わせてコンピューティング性能を拡張）| AWS

Amazon EC2 Auto Scaling は、アプリケーションの可用性を維持し、アプリケーションの要求に応じて Amazon EC2 の容量をスケールする方法を定義するのに役立ちます。

aws.amazon.com

App Scaling - AWS Application Auto Scaling - AWS

Learn how AWS Auto Scaling monitors your applications and automatically adjusts capacity to maintain steady, predictable performance at the lowest possible cost.

aws.amazon.com

オートスケールをやるにあたって必要なこと

1. インスタンス起動時に最新のコードを pull してきてアプリケーションを起動させる

オートスケールしてきたインスタンスだけコードが古いとエラーが発生する。

2. インスタンス停止時にアプリケーションのログファイルをどっか別のところに書き出す

Auto Scaling Group のインスタンスは Stop ではなく Terminate されるため、インスタンス破棄後もログを参照できるように S3 に上げるとかして永続化させる必要がある。 Fluentd や CloudWatch Logs に集約するのでも良い。

3. AMI を定期的にビルドする

オートスケール対象のアプリケーションは枯れていて今更新しいミドルウェアが追加されたりすることはなくてソースコードを git clone してくるだけで十分なのだが、 Gemfile に変更があった場合を想定して少しでもサービスインを早めるため（ bundle install を一瞬で終わらせるため）、 master ブランチへの変更が行われなくなる定時間際のタイミングで Packer でビルドして AMI にプッシュするようにしている。

Packer | HashiCorp Developer

Explore Packer product documentation, tutorials, and examples.

www.packer.io

4. Launch Configuration を自動作成

AMI のプッシュが成功したら最新の AMI を利用する Launch Configuration を作成し、 Auto Scaling Group も最新の Launch Configuration を参照するように変更する。 AWS CLI でできるので自動化してある。

5. Auto Scaling Group の設定をいい感じにやる

Auto Scaling Policy を決め（ CPU 使用率が一定水準を超えたらとか、 Load Balancer へのリクエスト数が一定以上になったらとか）、時間指定で Desired Count や Minimum Count を指定したければ Schedule をいい感じに組む。 AWS Management Console 上でポチポチするだけでよい。

6. deploy 対象の調整を頑張る

当初は Auto Scaling Group のインスタンスには deploy を行わない（業務時間中はオートスケールしない、夜間と土日だけオートスケールさせる）つもりだった。

しかしメトリクスを確認すると朝の通勤時間帯や平日の昼休み時間帯などにもアクセス数が多いことがわかったので一日中 Auto Scaling Group インスタンスを稼働させることにした。となると deploy 対象が動的に増減する、ということなので Capistrano の deploy 対象もいい感じに調整しないといけない。 AWS SDK Ruby で稼働中の EC2 インスタンスの情報はわかるので、 deploy 時には動的に deploy 対象を判定するようにした。

本当は push 型 deploy をやめて pull 型 deploy にするのがナウでヤングなのだろうが、レガシーアプリケーションに対してそこまでやるのは割に合わない。そのうちコンテナで動くもっとナウでヤングなやつに置き換えるのでこういう雑な対応でお茶を濁すことにした。

注意点

冒頭に書いているけどあくまで上記は EC2 インスタンスの Auto Scaling であり、周辺のミドルウェアは Scaling されない。例えば RDS を使っていたとして、 RDS インスタンスの方は拡張されないので Connection 数が頭打ちになったり、 CPU を使うクエリが沢山流れたりしたらそこがボトルネックになって障害になってしまう。周辺ミドルウェア、インフラ構成に余力を持たせた状態で行う必要がある場合は AWS Auto Scaling の方を使うことになると思う。

所感

1 と 2 のステップはすでに実現できていたので、自分は 3 、 4 、 5 、 6 をやった。オートスケール、めっちゃむずかしいものというイメージを持っていたけど、まぁまぁすんなり行った（二日くらいで大枠はできて、連休後半には実戦投入した）。負荷に応じて EC2 インスタンスがポコポコ増えて、週末の夜にパソコンを持たずに出かけられるようになった。これで家庭円満です。

オートスケールの設定をしているおかげでアクセスが集中する日曜の夜にもパソコンを持たずスシローに来店することができるけど、スシローの方がオートスケールに対応しておらず待合席で夫婦喧嘩をしながら 120 分待たないといけない。

— morygonzalez (@morygonzalez) May 13, 2018

問題点

Rails でデファクトスタンダードとなっているページネーション gem に Kaminari というのがある。

GitHub - kaminari/kaminari: ⚡ A Scope & Engine based, clean, powerful, customizable and sophisticated paginator for Ruby webapps

⚡ A Scope & Engine based, clean, powerful, customizable and sophisticated paginator for Ruby webapps - kaminari/kaminari

github.com

めっちゃ最高便利で大好きなのだけど、巨大なテーブルに対して COUNT 文を投げると遅いという問題にぶち当たった。このような巨大なテーブルで Kaminari を使うために COUNT 文を発行しない without_count というメソッドが用意されている（ Kaminari 1.0.0 でやってくる 5 つの大きな変更 - Qiita ）が、これを使うと next_page や prev_page 、 total_pages が取れなくなる（当たり前）。次のページがあるかどうかはばくち状態になってしまう。

本当は DB のスキーマを見直すべき（インデックスがちゃんと効くようにスキーマ変更するべき）だが、 Rails からもレガシーアプリからも同時に同じ DB にアクセスしており、並行運用しているような状況ではなかなか大胆な変更は実行できない。

DB 構造をなおせないとなるとキャッシュを思いつく。 HTML も Rails でレンダリングするのであれば partial cache などでページャー部分だけをキャッシュすれば良いが、 API 選任野郎と化した Rails ではビューのキャッシュはできない。

どうしたか

total_count をキャッシュする。公開範囲を設定できるようなリソースだと全員同一のキーでキャッシュするわけにはいかないのでユーザーごとにキーを作ってキャッシュする必要あり。全ユーザーの全リクエストでスロークエリになってたやつが 5 分に一回スロークエリになるくらいだったら何とか許容できる。

例えば以下のようなコントローラーがあったとする。 HeavyModel には数千万レコードあって、普通に COUNT 文を投げると遅い。 Paginatable という名前でモジュールを定義して、 render メソッドを上書きし、ページネーションを間に挟み込む。

class HeavyModelController < ApplicationController
  include Paginatable

  before_action :login_required

  def index
    resources = HeavyModel.all
    render json: resources, paginate: true
  end
end

モジュールはこんな感じ。車輪の再発明をしている感はあるが、 COUNT 文の結果が current_user 、コントローラーのクラス名、アクション名のそれぞれをつなげたものをキーにしてキャッシュされる。

module Paginatable
  def render(*args)
    options = args.extract_options!
    resources = options[:json]
    if options[:paginate]
      resources, meta = paginate(resources, cache_total_count: options[:cache_total_count])
      options[:json] = resources
      options[:meta] ||= {}
      options[:meta].merge!(meta)
    end
    args << options
    super(*args)
  end

  def paginate(resources, options = {})
    parse_params_for_pagination
    paginator = Paginator.new(
      resources:         resources,
      page:              @page,
      per:               @per,
      cache_total_count: options[:cache_total_count],
      cache_key:         total_count_cache_key
    )
    [paginator.resources, paginator.meta]
  end

  def total_count_cache_key
    @total_count_cache_key ||= "#{current_user&.id}_#{self.class.name}_#{action_name}_count"
  end

  class Paginator
    attr_reader :cache_total_count

    UNCOUNTABLE = -1

    def initialize(resources:, page:, per:, cache_total_count: false, cache_key: nil)
      @_resources        = resources
      @page              = page.to_i
      @per               = per.to_i
      @cache_total_count = cache_total_count
      @cache_key         = cache_key
    end

    def resources
      @resources ||= if cache_total_count?
                       @_resources.page(page).per(per).without_count
                     else
                       @_resources.page(page).per(per)
                     end
    end

    def page
      @page.zero? ? 1 : @page
    end

    def per
      @per.zero? ? Kaminari.config.default_per_page : @per
    end

    def meta
      {
        current_page: current_page,
        next_page:    next_page,
        prev_page:    prev_page,
        total_pages:  total_pages,
        total_count:  total_count
      }
    end

    alias cache_total_count? cache_total_count

    def paginatable?
      !cache_total_count? && resources.respond_to?(:total_count)
    end

    def current_page
      resources.current_page || page
    end

    def next_page
      paginatable? ? (resources.next_page || UNCOUNTABLE) : next_page_fallback
    end

    def next_page_fallback
      return UNCOUNTABLE if page < 1
      return UNCOUNTABLE if per > resources.length
      total_count_fallback > current_page * per ? current_page + 1 : UNCOUNTABLE
    end

    def prev_page
      paginatable? ? (resources.prev_page || UNCOUNTABLE) : prev_page_fallback
    end

    def prev_page_fallback
      return UNCOUNTABLE if page < 2
      (total_count_fallback.to_f / per).ceil >= page ? current_page - 1 : UNCOUNTABLE
    end

    def total_pages
      paginatable? ? resources.total_pages : (total_count.to_f / per).ceil
    end

    def total_count
      paginatable? ? resources.total_count : total_count_fallback
    end

    def total_count_fallback
      @total_count_fallback ||=
        begin
          cached_total_count = Rails.cache.read(@cache_key)
          if cached_total_count
            cached_total_count
          else
            real_total_count = @_resources.page(page).total_count
            Rails.cache.write(@cache_key, real_total_count, expires_in: 5.minutes)
            real_total_count
          end
        end
    end
  end
end

これで 5 分間はキャッシュが効くようになる。

先日書いた Day One のバックエンドで障害 - portal shit! について、 Day One のヘルプページで詳細を説明する記事が掲載されていました。

Help Guides

The Day One Help Guides are designed to help you with tutorials, tips, and documentation for the Day One journal app.

help.dayoneapp.com

ウェブアプリケーションエンジニアの皆さんが読むと参考になるのではないかと思い、翻訳の可否をたずね許可をもらったので翻訳します。

2018 年 5 月の Day One 障害報告

執筆者： Paul Mayne （訳注：Day One の創業者）
今週更新（訳注：障害復旧日の午後に公開されました）

2018 年の 5 月 7 日から 10 日にかけて、 Day One は重大な Sync サービスの停止に陥りました。ユーザーの皆さんから堅牢な Sync サービスを期待されていることはわかっていますし、この出来事は我々の基準を満たすものでもありません。何が起こったのか、そして将来にわたってどのようにこの問題を回避していくかをユーザーの皆さんにお伝えしたいと思います。

簡単なまとめ

5 月 7 日にハードウェア障害が発生し、最初の Sync サービスの停止が発生しました。バックアップデータが不完全だったことが原因で、 5 月 8 日の Sync サービスの復旧処理中、一部のユーザーのアカウント ID が既存のユーザーのものと重複してしまいました。結果、一部の新規登録ユーザーは他人の記事を見ることができる状態となっていました。問題に気がついてすぐに Sync サービスを再び停止させました。対象のユーザーは 106 人で、これは我々のユーザー全体の 0.01% よりも少ない値です。

現在、 Sync サービスは正常に復旧しており、記事が他人に見られることはありません。近日中（訳註：すでにリリース済みです）に意図せず共有されてしまった記事を削除するアップデートを提供します。

End-to-end の暗号化を施していた記事は今回の事故の対象外です。

いかなる偶発的な個人情報の漏出も信用を毀損するものであると我々は認識しています。この不幸な状況にあって我々は、正直に状況を説明することが最善だと思っていますし、また信頼を回復するために全力を尽くしています。今回、個人情報の流出被害にあった 106 人のユーザーには終身の Premium メンバーシップを無償提供し、それぞれ個別に連絡を取っています。自分たちにできるあらゆることを行ってみなさんの信頼を回復していきたいと思っています。

障害の詳細

5 月 7 日月曜日、 Day One の社員が DB サーバーでハードウェア障害が発生していることに気がつきました。問題のあるサーバーをデータベースクラスターから取り除く作業とデータを残りのサーバーに分散する作業を始めました。

データの分散処理に失敗します。これが最初の障害です。すぐに Sync サービスを復旧させたかったため、新しいデータベースクラスターを作成して最新のバックアップデータを読み込むことにしました。新しいクラスターがセットアップされ、バックアップが読み込まれました。

5 月 8 日火曜日の早い時間に復旧処理が完了し、 Sync サービスを再開しました。当初は順調に動いているように見えました。しかし数時間で「自分の記事ではない記事が見える」という問い合わせが何人かのユーザーからありました。これは由々しき事態であり、我々はすぐに Sync サービスを再停止し、これ以上被害が拡大しないようにしました。

この時点で、問題と対応方法の調査を行う間、 Day One Sync を無期限に停止する旨をソーシャルメディアに投稿しました。何が原因なのか、何が起こっているのか、そしてもう問題が起こらないと確信できるまで Sync サービスは再開できませんした。

5 月 9 日水曜日の午前、問題の根本原因を突き止めました。復旧処理に用いたバックアップデータが不完全だったのです。記事データは完全なものでしたが、ユーザーアカウントデータに欠落がありました。具体的には、 3 月 22 日よりも後に作られたユーザーアカウントデータが含まれていなかったのです。その結果これらのユーザーはログインすることができていませんでしたし、特定の記事データが意図せず他人から見えてしまうという問題につながりました。

それぞれの記事データベースは “accountID” というフィールドを持ち、どのアカウントがその記事の所有者であるかを判断しています。全ての記事データは正しく復旧されましたが、ユーザーアカウントデータはそうではなかったため、データベースに所有者が存在しない記事ができてしまいました（例えば “My Travel Journal” という記事は 123456 というアカウントのものだったとしましょう。しかしそのアカウントが存在しなくなってしまったということです）。新しいユーザーアカウントの ID は連番で作られます。復旧されたデータは最新のユーザー情報を含んでいなかったため、 5 月 8 日に新規登録したユーザーは本来よりも小さな値の ID で登録され、既存のユーザーアカウントと重複することになったのです。その結果、これらの新規ユーザーはすでに存在する他人が書いた記事を読めるようになってしまったのです。

5 月 8 日の問題が発生していた期間のうちに、 326 アカウントが正しくない account ID で作成されました。その 326 個の ID のうち、 106 個が別人によって書かれた既存の記事データに結びついていました。 2018 年の 3 月 22 日から 23 日に作成されたアカウントは他人から記事が見られる状態になっていたということです。それらは account ID 1104506 から 1104831 の人たちでした。

現在のところそれらの記事のうちどれくらいが end-to-end の暗号化処理をされていたかはわかっていませんが、 end-to-end の暗号化をしていた記事は今回の問題でも他人に見られることはありませんした。

水曜日の調査の後、元のデータベースでデータの分散処理に失敗する問題を解決することが最善の選択肢だと判断しました。いくつか設定ミスがあり、データベースの負荷が高まる原因になっていることがわかりました。この負荷が原因でデータの分散処理が失敗していました。

水曜日の午後、この問題を修正し、元のデータベースクラスターで分散処理が正しく完了することを確認しました。しかしエンジニアチームとサポートスタッフが万全の態勢で臨めるよう、 Sync サービスの再開を木曜の朝まで遅らせることにしました。山岳時間で 5 月 10 日木曜の午前 8 時、 Sync サービスは再度有効化されました。

同期サーバーには大量の待機処理があったため、それらの処理が終わるまでは少しパフォーマンスに問題があるかもしれませんが、なるべく遅延が発生しないように対処しています。

今後どうするのか？

意図せず共有されてしまった記事を削除する機能が入った Day One.app のアップデート（バージョン 2.6.4 ）をすぐにリリースします（訳注：すでにリリース済みです）。このアップデートをインストールすると、未ログイン状態のユーザーの端末からは非公開の記事はすべて削除されます。対象ユーザーはアップデートのインストール後 30 日以内に Day One アカウントにログインすることが必要で、このログインをもって Day One.app はログインユーザーを記事の所有者であると認定し、記事を復元します。 Day One.app は影響を受けるユーザーに対してこの変更内容を通知します。

今後、同様の問題が起こらないように、近々以下の改修を同期サーバーに対して施します。

1. account ID の新規作成時、すでにその ID で記事が作成されていないかをチェックします
2. 新規の account ID に対しては、連番の数字に加えてランダム生成された二桁の数字を末尾に付加することにします。将来、同じような問題が発生して連番 ID が若返ってしまったとしても ID の衝突が起こる可能性は非常に小さくなります。
3. いくらかのユーザーアカウントがバックアップ対象から除外されてしまう問題を修正します。

他人に記事を見られてしまった 106 人のユーザーに対しては真摯に謝罪します。対象のユーザーには終身 Premium メンバーシップを提供するとともに、その他懸念点がないか個別に連絡をとっています。今回、大規模な情報流出は起こっていません。第三者がデータベースに侵入したということもありませんし、すべてのデータは我々のサーバーで安全に保管されています。しかしながら 106 人のユーザーの我々に対する信頼は失われてしまいました。信頼は獲得するものであり、与えられるものではないということを承知していますし、再び皆さんからの信頼を取り戻せる機会を得たいと思っています。ユーザーの皆さんには 2017 年 6 月にリリースした end-to-end の暗号化機能を利用することを推奨します。この機能は今回のような事故やその他の問題があったときにもあなたの個人情報を保護します。

今回の障害で Sync サービスを利用できなかった間、辛抱して下さったユーザーの皆さんに感謝します。皆さんが Day One を使って大事な思い出を記録していることを理解しています。今後、よりよくしていくことをお約束します。信頼を回復するため、全力を尽くします。

— Paul

真似して書いてみます。

キャッシュレス生活2018 in 京都 - 『言葉を吐く』

結論 2018年の日本において100%キャッシュレス生活は厳しい 京都ではなおのこと厳しい しかし実際的な満足度は非常に高い 財布の中身 クレジットカード SMART ICOCA キャッシュカード (デビットカード) (EX-IC) (オフィスのカードキー) 普段はクレジットカードを使う。最近、ローソンではクレジットカードを店員側で端末に挿入せず客側で挿入するようになって、良い改善だと思う。 あとは交通手段としてSMART ICOCAを使っている。Apple Pay/Suicaモバイルはスマフォからチャージできてたいへん便利そうでうらやましいけど、iPhoneを選ぶつもりはないしおサイフケータ…

d.aereal.org

キャッシュレス生活2018 in 京都 - hitode909の日記

フレスコ(スーパー)でクレジットカード使えるようになったのが革命 そのおかげで最近あまり現金に触れずに過ごしている 平日はほぼ現金触れずに暮らすことが可能 家でご飯食べている 買い物する場所はコンビニかフレスコかドラッグストア，いずれもクレジットカード使える 会社の裏のサンドイッチ屋では使えない 金曜日や週末は飲みに行く 店でカード使えたら払わせてもらって，同席した人たちから現金を調達することで，なるべくATMに行く回数を減らしている 金曜によく行く天ぷらバルではカード使える 週末はだいたいデンエンかサイゼリヤに行く学生みたいな暮らしをしている．デンエンではカードが使える．サイゼリヤは使えない…

blog.sushi.money

キャッシュレス済み

Apple Pay

大手資本が関与しているものは基本的に Apple Pay （ iD ）で払っている。めっちゃ快適。

• コンビニ
• ドンキホーテ
• カルディ
• ドラッグストア
  • ココカラファイン
  • マツモトキヨシ

カード払い

• 酒のやまや
  毎週末酒を買いに行ってるやまやは Edy が使えるが、 Edy のポイント還元率はしょぼいのでクレジットカード払いしてる。やまやはドコモの d ポイントも貯まるのでカードのポイントと d ポイントでマイル乞食がはかどる。
• ジュピターコーヒー
  カルディのパクリみたいな店でコーヒー豆を買うときにカード払いする。交通系電子マネーで払えるがポイントが付かないのでカード払いしてる。
• 昼食
  普段は弁当なので昼飯に金を使わないが、稀に弁当を準備できなかった日は会社近くのスーパー（ SUNNY ）でカード払いする。
  マイル乞食したいのでカード払いできない飲食店に入って食べるということをしなくなった。
• コストコ
  もう会員証が失効したけど行ってた頃はわざわざコストコ用に Saison Walmart American Express カードを作って払ってた（コストコは提携カードブランドでないとクレジットカード使えない）
  いまは提携カードブランドが AMEX から Master に変わってる

その他

• ガソリン
  Esso で Express 給油。 Speedpass で Apple Pay 並みに高速に金が払える。
• 高速代
  ETC カードで払う。
• 税金
  去年までは楽天カードから nanaco にチャージしてポイント還元を受けながら納税してた。固定資産税と自動車税合わせて年間 14 万くらい。
  今年から楽天カードが nanaco チャージにポイントを付与しなくなったので SEVEN CARD を作って nanaco チャージして払う方法に切り替えた。
  nanaco は税金を払うのにしか使わずセブンイレブンでも買い物は基本的に Apple Pay （ iD ）で払う。
  

キャッシュレス未完

• 自宅近辺のスーパー
  どこもカード払いできないのでちまちま現金払いしてる。
  福岡のスーパーでカード払いできるのはサニーか西鉄のレガネットか高級スーパーのボンラパスくらいだと思う。
• 近所のコーヒー豆屋、パン屋、飲食店
  個人商店ではカード払いできない。現金での買い物は極力したくないので結果的に本当に気に入っている店でしか買い物しなくなった。

所感

守銭奴なので基本的に快適性や利便性は二の次で、ポイントが貯まることを重視している。なので交通系電子マネーか Edy のみが使える店では電子マネーを使わずカード払いするしカード払いできないなら現金払いしてる。中途半端に残高が分散するのが嫌なのでチャージ式の電子マネーは nanaco だけ使うようにしてる。それも税金の支払いにしか使わない。一時期は Apple Pay で払うのが面白くて iPhone の Mobile Suica を多用していたけど ANA VISA カードによる Mobile Suica チャージではポイントが付かないことを知って使うのをやめた。

ベストエフォートキャッシュレス化のおかげでデカい財布いらなくなって Bellroy のカード入れに非常用現金数千円を畳んで忍ばせてあとは小銭入れと Apple Pay 付き iPhone だけ持ってうろついてる。 Bellroy のカード入れはめっちゃ薄いので身軽になって嬉しい。

Apple Pay やその他の支払い方法で挙げた ETC カードや Speedpass 、 nanaco も結局はクレジットカードが終端にあり、大意ではクレジットカード払いであると言える。これがネックになってキッャシュレス決済に店側の負担（決済手数料）が発生して大手資本以外でキッャシュレス決済が普及しない遠因になってる気がする。カード決済は個人商店だと 4.5% くらい決済手数料を持ってかれる。 Square とかを使ってもせいぜい 3.25% （ JCB に至っては 3.95% ！）までしか落ちないはず。電子マネー決済も似たり寄ったりだと考えられる。クレジットカードを介さないキャッシュレス決済が普及したら手数料が下がり個人商店でも導入できて便利になりそう。

ちなみに中国人観光客が多いキャナルシティ博多では普通に中国人が WeChat Pay だか Alipay だかで QR コード払いしてるので、同じように外国人観光客が多く利用する中洲の屋台なんかの方がスーパーや個人商店よりも先にキャッシュレス化されるかも知れない。

福岡ではまだまだ完全キャッシュレスな生活を送ることは難しいが、頑張れば現金を使う機会を結構減らすことができる。現金は飲み会の割り勘とか祝儀・不祝儀を包むためだけに存在するようになるかもしれない。

東京の富裕なエンジニアのお二方にも書いてもらえたみたいだった。

キャッシュレス生活2018 in 東京｜すらいむ

真似して書いてみます。 ・キャッシュレス生活 2018 in 福岡 - portal shit! ・キャッシュレス生活2018 in 京都 - 『言葉を吐く』  ・キャッシュレス生活2018 in 京都 - hitode909の日記 普段の持ち物はiPhoneとマネークリップのみで、よく使う順にiD・Suica・クレカ（ビックカメラSuica）です。 iD Amazonカード付帯のものをApple Payで使ってます。クレカ直引き落としで残高気にしなくて済むのが便利。よく使うのはここら辺。 ・コンビニ ・書店 　・Book1st、啓文堂、ツタヤあたりで使える

note.mu

note ご指定のページが見つかりません

note.mu

Day One という日記書きソフト、愛用しているのだけど今週頭に障害が発生して日本時間で 2018/05/11 の明け方まで同期ができない状態になってた。

Day One の Sync Service 死んでるの不便…。 Twitter とかへのポストを IFTTT 経由で取り込む機能も止まってる…https://t.co/gXLiispKfl

— morygonzalez (@morygonzalez) May 9, 2018

Help Guides

The Day One Help Guides are designed to help you with tutorials, tips, and documentation for the Day One journal app.

help.dayoneapp.com

ユーザーとして不便だったけど復旧にかなり時間がかかったのがソフトウェア開発者の一人として興味深かった。何が原因で復旧が遅れたのか推測した。

Day One のバックエンドは AWS に構築してあるようで、負荷でサーバーがダウンしたのなら EC2 インスタンスを追加してサーバー再起動すれば良いはずなのですぐ復旧できるはずと思ったが、一向に復旧しない。復旧作業の状況報告ページにしきりに “server rebalance” というフレーズが出てきており、アプリケーションサーバーで “rebalance” なんてことはやらないから、どうもデータベースがクラッシュしたようだった。

Day One のバックエンドエンジニアの採用情報見たら技術スタックが書いてあって、開発言語は Scala で DB は Couchbase を使ってるとのことだった。で、 Couchbase では Shared Cluster の rebalance という作業が必要らしい。

Couchbase は CAP 定理のうち一貫性と分断耐性を保証していて、その代わりに可用性が犠牲になっている（Couchbase Server - Wikipedia）。 Day One では複数のクライアントからほぼ同時に同一ドキュメントに対して更新が走ることが多いし、 iOS からは不安定なモバイル回線経由で接続される。かつては Dropbox や iCloud も同期のバックエンドとしてサポートしていたが、コンフリクトしたり意図せぬデータ欠落などがあったと思われ、自前のバックエンドシステムに移行したのだろう。一貫性と分断耐性に特化した Couchbase はユースケースとして最適に思えるが、障害が起こるとリバランスに手間取り復旧の難易度が上がるようだった。

自分は大規模分散データベースみたいなやつは受託の会社に勤めてた下っ端の頃にしか使ったことがなく、自分でがっつり運用・構築したことがないので大規模データベースに対する知識が足りていないと思う。大した考察は出来ていないが、今後もバックエンド API おじさんとして余生を過ごしていく上で参考になる出来事だった。そのうち詳細な post-mortem が Day One のエンジニアによって公開されるようなのでこちらもあとで読んでおきたい。

あまりに復旧が遅かったのでこのままサービス終了するのではないかと心配になったが、何とか復旧出来たようである。 Day One のバックエンドの皆さんおつさまでした 🍵

前書いてた記事の続き。

🏭 Docker を Production 投入するメリットを考える

仕事で開発中のシステムで、 master ブランチに Pull Request が Merge されると自動的に AWS ECS に構築した社内向けの確認環境にデプロイが行われるような仕組みを導...

portalshit.net

Kaizen Platform 時代は Naoya Ito さんの以下の記事にあるような感じで deploy してた。 Slack 上で hubot に話しかけると deploy 用の Pull Request が作られていい感じに deploy フローが始まる。

GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー

少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分…

d.hatena.ne.jp

これがめっちゃ良くて、現職場でも導入したいと思ってたので今週ちょっとやってみたところ deploy できるようになった。

実際のデプロイフロー

まず Slack で hubot （ 山の会社なので tengu という名前にしてる）に話しかける。すると hubot で GitHub の API を叩いて deploy 対象の Pull Request を取得し、それぞれの Pull Request ごとに commit をグルーピングして、 deploy 対象の Pull Request の Author にメンションするかたちで master ブランチから deployment/production ブランチへの Pull Request が作成される。

最近 Slack の GitHub Integration がアップデートされて、 Webhook の通知がいい感じに飛んでくるようになったので Slack 上でどんな内容が deploy されるのかが一目瞭然となる。

実際に作成される Pull Request は以下のような感じ。この Pull Request を Merge することで CircleCI 上で deploy 用のビルドが走る。その辺は Naoya さんの記事で書いてあるのと同じ。

いま作ってるやつは AWS ECS で運用しようとしてるので、 cap deploy ではなく手製のシェルスクリプトで以下のことをやっている。

1. deploy 用のコンテナイメージをビルド
2. AWS ECR にコンテナイメージをプッシュ
3. プッシュしたイメージを利用する Task Definition を追加し、 ECS のサービスを更新 ecs-deploy というシェルスクリプトでやる

以前の記事にも書いたが「 CircleCI が落ちてたら deploy できないじゃん？」というツッコミが入ったため CircleCI が落ちていても deploy できるようにシェルスクリプト化してあるので、手元からおもむろに bin/deploy production とかやっても deploy できる。

ちなみにこのフローを実現する .circleci/config.yml は以下のような感じ。

jobs:
  deploy:
    docker:
      - image: docker:17.05.0-ce-git
    steps:
      - checkout
      - setup_remote_docker:
          docker_layer_caching: true
      - run:
          name: Install dependencies
          command: |
            apk add --no-cache py-pip=9.0.0-r1 jq curl curl-dev bash
            pip install docker-compose==1.18.0 awscli==1.14.38
            curl -s https://raw.githubusercontent.com/silinternational/ecs-deploy/ac2b53cb358814ff2cdf753365cc0ea383d7b77c/ecs-deploy | tee -a /usr/bin/ecs-deploy && chmod +x /usr/bin/ecs-deploy
      - run:
          name: Execute deployment (Docker image build, push to ECR, create new Task and replace container)
          command: |
            case ${CIRCLE_BRANCH} in
              "deployment/dev" | "master" )
                DEPLOY_ENV="dev" ;;
              "deployment/production" )
                DEPLOY_ENV="production" ;;
            esac
            bin/deploy ${DEPLOY_ENV}

workflows:
  version: 2
  production-deploy:
    jobs:
      - deploy:
          filters:
            branches:
              only:
                - deployment/production

Chat deploy のよさ

deploy フロー・ deploy 状況が可視化され、民主化されることがよい。昔ながらのローカルからの capistrano による deploy の問題点は deploy の特権化を招いてしまうことだと思う。 ○×さんしか deploy 用の踏み台サーバーに ssh できないので一々○×さんに deploy をお願いしないといけない、というような状況はよく分からない遠慮や序列を招きがち。 deploy フローが自動化されていることでチームに入ったばかりの人でもさくっと deploy が行えるというメリットもある。

deploy の履歴が Slack 上と CircleCI 上、また GitHub 上に Pull Request として残るのもよい。ひとくちに deploy といっても schema 変更が伴う場合は作業ログの共有やコミュニケーションをどこかで行う必要があり、その場所として GitHub の Pull Request が使えるのがとてもよい。 YAMAP で作った deploy スクリプトではそこまでやってないが、 Kaizen Platform の deploy スクリプトには deploy 用の Pull Request 本文に動作確認用のチェックボックスを作って、チェックボックスにチェックが入れられるまで cronbot が二時間おきに deploy 対象の commit author に Slack 上で動作確認を促す、というような仕組みまであった。

今後 YAMAP でもどんどん deploy フローを改善していって Merge ボタンを押したあと寿司を食ってれば良いような状態[^{1]にしていきたい。}

ちなみに上記の chat deploy を実現するためには GitHub App を作っていろいろやる必要があって、その辺は Kaizen Platform で同僚だった t32k さんの以下の記事が参考になった。

チャットデプロイしたい2018 - MOL

タイトルの通り、チャットデプロイしたい。

t32k.me

書いてあるフローはほとんど Kaizen Platform のやつと同じでちょっとウケた。いやでもそのくらい完成されてる仕組みだと思う。この割とイケてる deploy フローを体験してみたい人は僕が勤めてる YAMAP の Wantedly をご覧下さい。資金調達しており割と積極的に採用中です。

• 株式会社ヤマップの会社情報 - Wantedly
• 山登りの地図アプリ「YAMAP」が12億円調達、業界で連携し登山者の裾野を広げる | TechCrunch Japan

[^1]: Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note http://blog.glidenote.com/blog/2015/02/18/terraform-github-circleci-atlas-aws/

[B! リモートワーク] リモートワークのストレス | POSTD

この記事に対して146件のコメントがあります。注目されているコメントは「寂しがり屋と真面目君はリモート向いてない」、「リモートワークって、ペアプロやモブプロが推奨されるアジャイルや、少人数で効率よく検証・開発のサイクルを回すリーン的な働き方と相性悪いと思ってる。」、「たまにリモートにするぐらいが丁度良い派」、「7割はチャットの下手さが理由だと思う。対面での会話が得意すぎるとも言うが。」などです。

b.hatena.ne.jp

リモートワーク別に寂しくないし楽勝、みたいなコメント多いけど違和感あった。リモート楽勝という人はフリーランスとか受託の会社の人なのではないかと思う。自分のブックマークコメントは以下。

激しく同意。雑談したい、家族から家事を頼まれる、オフィスにいる連中から事業理解が低いと責められる、毎日服を着替える能力や通勤電車に乗る能力が失われる、などなど — http://b.hatena.ne.jp/morygonzalez/20180309#bookmark-359971190

「こいつはわかってない」問題

自分の場合は事業会社に所属した上でのリモートワークだった。事業会社（大抵のスタートアップもこれに含まれるはず）の場合はソフトウェアエンジニアにも事業やプロダクトへの理解が求められるので、リモートだとなかなか厳しい部分がある。事業理解は日々の MTG の他、オフィスで何気なく交わす雑談や昼飯の時なんかに醸成されるものだと思うので、リモートだと MTG での情報伝達密度が下がるし雑談や昼飯に至ってはそもそも不可能なので自分自身の事業理解も深まらない。仮にこちらに事業に対する理解があったとしても、それをオフィスにいる連中に伝えることが難しいので結局「こいつはわかってない」という烙印を押されることになる。リモートワークやってて同僚のエンジニアの皆さんとは友好関係を築けたと思うけど、 PM や上司とはなかなか良い関係になれなかった。

家庭内で仕事が軽んじられる

家族がいる人の場合は家族が「こいつ家にいてあんまり忙しくなさそうだから家事を頼もう」ということになりがち。自分の場合は子どもの幼稚園の送り迎え（バス乗り場まで）、幼稚園から帰ってきたあとの子守、洗濯物干し・取り込み、などを頼まれることが多かった。配偶者も仕事をしていて家事を分担する、ということなら当然やるけど、我が家の場合は嫁さんが習い事やヨガで忙しいので家事をやらなければならない、という感じで、自分の仕事は嫁さんの習い事よりも優先度が低いものなのだろうかと悶々とした。

社会適応能力の低下

毎日身支度をする能力、出かけていく能力も確実にむしばまれていく。転職してリモートワークからオフィスワークに切り替えて、朝の混んでる時間の電車に乗る通勤生活を再開してからの数ヶ月間は肉体的にも精神的にも非常につらかった。また家で仕事してると出歩かないので当然に運動不足になる。自分で意識してジョギングしたり体を動かしたりしないと確実に健康を損なう。

自分がリモートワークに対して否定的な見解を持っているのは以上のような背景があるのであった。

良い面もある

もちろんリモートワークには良い面もある。

ワークライフバランス

子育てのための一時期や家族の看病が必要な時期には非常にありがたい制度だと思う。ワークライフバランスは非常に良好になる。

集中維持

コード書きに集中したいときにもリモートワークは便利だった。リリース前など、移動の時間も惜しんでコードを書きたいときには朝 10:00 から夜の 24:00 頃まで風呂とトイレと飯の時間以外はずっと仕事してたこともあった。それでも 10 時間は時間が空くので十分睡眠をとることはできる。これも前にブログで書いたような気がするが、いつでもオフィスに仕事しに行ける環境で、自分の裁量で週に数日リモートで仕事をするのが一番満足度の高い働き方になると思う。

地方都市に暮らしながらデラウェア法人で働ける

あとそもそも福岡では前職のような数十億円規模の資金を調達してがつんと成長しようとしているスタートアップの仕事にありつくことなんかは不可能なので、田舎に住んでいても都会のイケてる手法で仕事できてたのはリモートワークならではだったと言える（これも元記事に書いてある）。いまの職場でやってることは前職で身につけた¹もの（スタートアップで働くエンジニアのディシプリン的なもの、あるいは技術顧問おじさんの素養）を土台にしているので、これは非常にありがたかった。

まとめ

ひとくちにリモートワークといってもいろいろな形態、状況があるので、↑の記事のブコメのように「リモートとか楽勝じゃね？」というコメントを読んでうかつにリモートワークを始めようとしている人がいたとしたらちょっと踏みとどまってもらいたいし、自分に向いているか、勤務先のビジネス領域・ビジネスモデルなども加味した上で決めてもらいたいと思う。

あとリモートワークだとコードレビューが甘くなりがちではないか、という問題もあるけどそれはまた別の話かもしれない。

リモートワークしてた頃、コードレビューの指摘・修正往復を沢山したくなくて（修正してもらった後にさらに注文つけるのきつい）、本当は修正して欲しいけどLGTMすることあったけど、オフィスで仕事してると追加の指摘をしたあとに口頭で補足説明できるので割と納得できるまでレビューできる気がする。

— morygonzalez (@morygonzalez) March 8, 2018

References

• リモートワークのストレス | POSTD 翻訳記事
• The Stress of Remote Working – Hacker Noon 元記事
• Kaizen Platform という会社について - portal shit!
• リモートワーク - portal shit!