物を書く習慣は手につかず、今日久しぶりに書いてみます。

３月いっぱいで勤めていた会社を辞めて、４月から別の会社に行きます。ちょうど今は有給消化期間になります。
なので、１６時の開店に合わせてHUBのHappy Hourでジントニックを飲みながら唐揚げ食べて、みたいな優雅なこともできます。

有給消化期間

今回は駄文なのであしからず。

以前、「INDEPENDENT」という本を読みました。会社員だったら有給消化期間というなの元、どう過ごそうが一定の自由があります。役割も役割だったのもあり、残した仕事も一部ある気がしていたので、簡単な相談等はきますが、業務とも言い難いような内容だったりするので、流してますが。

海外だとこういうまとまった有給消化期間をガーデニング休暇やサバティカル休暇なんて言って、競合他社に移籍するのもたまにあるし、そもそもバケーションがしっかりあるので、日本とは違い、身も心も休まる時間がちゃんとしてますね。日本人ほど鬱病にはなってないんじゃないかな。

ところでなんで退職？

約一年半、とある会社にいたわけですが、退職しました。事業のスピード感や、組織が求める人材じゃなかったのが露骨に感じたしね。
欲しいのはSystem Integrator(SIer) で上級幹部職上がりの人、 事業会社のエンジニア、プログラマーじゃなかった会社でした。
最後の方は「なんでこの会社いるんだろう、自分。どんだけ時間無駄にしてたんだろう、少なくとも半年以上棒にふっちゃったな」、振り返ると良くは思えず、良かったのはなんだろう。。。あったかな笑、という感じで退職に至りました。

一番は、新しい生き方、働き方、チャレンジがしたい自分がいるのに、変化を許容する気がない組織があり、世間から２歩３歩遅れて動いている組織に嫌気がさしたこと。
水と油が混じらないのと一緒で、このまま混ざらずに終わるのを待てなかったのでこのタイミングでの退職になりました。
幸いなことに有給が付与されたてで時間も得られたのでいろんな勉強をしようと、３月頭は息込んでました。あくまで息込んだまで。

残り半月

残り半月、できることは限られてるので、次の会社のいくつかの勉強しつつ、FX を少し勤しむ予定です。久しぶりにPHP触ったな笑あとはビジネス書読みあさったり、経済、投資、できることをできるだけやろうと思ってます。引っ越しも考えたいな。次こそVDSLじゃなく光回線のところに！！

はじめに

４月から以前よりも大きなサービスを扱っている会社に転職しました。以前の職場でもプレスや大型ニュースサイト等で取り上げられると「システム大丈夫なんだろうか？」「噂っていうフラグで、おちるわけないだろwww」「うわ、落ちた」みたいなことがありました。時として「突風」が吹くこと、予期した「暴風」が来ることがこの界隈はあり得ます。

そんなこんなで、過去を振り返りつつ、突風を凌ぐためにしたことを書いていこうと思います。

※ ここでは、手軽く、エンジニア的な知識がなくても提案できそうな内容を記載します。最低限まずはこれはできるよね、の個人的なリストにしたく、今回まとめてます。本当の気休め程度の情報です。

問題はこれだけじゃないので、悪しからず。そしてこのブログはそこまで考えたサーバーではございません。

ボトルネックを最低限知っておく

これまで携わったサービスで原因になったことは大体、

• データベース CPU
• データベース Connection
• 同時接続数

だいたいデータベース、あとは同時接続、何かが鍵だと思います。大事なのは、どの画面、どの処理が負荷が高いのか、どうすると危ないのかなどをしっておくことです。

負荷をかけてるバッチを止めてみる

バッチとは、定期実行される処理をバッチ（Batch）と呼んだりします。毎分、毎時で行うような処理を登録しておき、計算させたり、データを登録したりなどしています。

このバッチですが、実行された際、一定時間 データベースに負荷をかける状態ができるものだとします。バッチの実行タイミングで、「突風」が吹いてしまっている場合、ユーザが見えるところに支障がでる可能性があったり。

基本的に、今までいた職場だと重たい処理を実行する場合、アクティブユーザが少ない時間帯での実行だったり、データのレプリカを別のデータベースに転送し終えた後で、独立したバッチサーバーでバッチの実行をしていたのですが、どうしても毎分、毎時間、回さなければいけない、本番と切り離されていないバッチがある場合、「バッチを止めてみる」という手段があります。

とはいえ、ちゃんと時間帯や条件を管理しておけば、バッチを止めずしもどうにかなります。

キャッシュが効いてるかどうか見直す

サービスによってですが、同じ情報を繰り返し取りに行く箇所があったりします。例えば、未ログインユーザと、ログインずみユーザで表示を出し分けてて、未ログインユーザに見せる情報をデータベースから取りに行く、など。その際都度リクエストが生じる状態だとしたら、瞬間風速が吹き荒れた、対象ページがそれだったら「逝き」ます。会員制サービスじゃなくても都度情報を取りに行くみたいなことが起こればいくでしょう。

そんな時のために、キャッシュを用意していて、時間で切れるようなキャッシュの場合問題にならないかなど、エンジニアと相談してみましょう。

静的ファイルに変える

更新頻度が比較的少ない場合、情報を静的ファイルに置き換え対処するのも１つの手です。例えばAPIレスポンスをjsonファイルに出力、基本的に利用する側はjsonファイルを見て、batch等でjsonファイルを一定周期で更新できれば問題ない場合があります。

以前の職場でワードプレスを利用していて、rssを取得する処理起因で、サービスが落ちたことがありました。もちろん当たり前のデータベースのキャッシュは効いていて、通常通りの利用であれば問題はなかったのですが、突風によってもらい事故を受けました。

簡単な説明ですが、データ（情報）を取りに行くという処理は、アクセスが増えると、ファイルをブラウザに渡すだけよりも苦しいということです。なので、ここでの対応は静的ファイルに置き換え、定期的に更新する、ということに変えました。

WordPressのフィードはデータベースから投稿情報を取得して、リスト化、XML形式として情報を返すものです。リクエストされた際にデータベースにアクセスし、データを取得するリクエストが起こります。ここがボトルネックになったりします。リクエストされた際、当然キャッシュがヒット、レスポンスをすぐ返すことはしているのですが、膨大なリクエストであると捌ける必要もなく。もちろん相応のスペックのサーバーを用意しているなら大丈夫ですが、想定の範囲を超えたものがきたとします。落ちますね。

上記の例ですが、要件次第では大きな効果を発揮でます。データベースの負荷やコネクションを下げ、静的ファイルになるので、サーバーの設定次第で静的ファイルのキャッシュが有効になってたりするので、レスポンスタイムの大幅な改善にもつながったりします。

別の例で行くと、インデックスをはれなくなったデータベース（レコード数が膨大でサービスを止めなければいけないようなもの、パーティションやシャーディングができないもの）とかでもこのアプローチであれば、一時凌ぎにはなります。

まとめ

簡単ではありますが、過去に携わったサービスの突風対策について触れてみました。サービスに携わっている人で、何かの一助になってくれれば幸いです。