読者です 読者をやめる 読者になる 読者になる

15分でできるサーバーレス死活監視

Webサービスの死活監視をするためだけに別途サーバーを用意すると、その死活監視用のサーバーが死んでたらどうしようとビクビクして夜も寝られなくなります。そこでサーバーレスにすればその不安もわりと減るよね、という話は色々なところでされているわけですが、それをなるべく簡単に実現しようということで方法をメモがてら記しておきます。

 

今回の構成を端的にまとめると、

  • AWS Lambdaを利用する
  • Lambdaへのデプロイにはchaliceを利用する
  • 監視対象の情報はiniファイルに記述する
  • iniファイルはS3に配置する
  • CloudWatch Eventsによって定期的にLambdaを実行する

という感じです。

  

では早速作業してみましょう。AWSの各種サービスの扱いに慣れていれば15分もかからないと思います。

 

1. 事前準備

% sudo pip install chalice
% cat ~/.aws/config
[default]
region = ap-northeast-1
aws_access_key_id = <YOUR ACCESS KEY>
aws_secret_access_key = <YOUR SECRET KEY>

 

2. プロジェクトの作成/ソース配置/ひとまずデプロイ

% chalice new-project serverless-health-checker
% cd serverless-health-checker/
% ls -a
./  ../  .chalice/  .gitignore  app.py  requirements.txt
% git clone https://github.com/phero/serverless-health-checker-src.git
% ln -sf serverless-health-checker-src/* .
% chalice deploy
Initial creation of lambda function.
Updating IAM policy.

The following actions will be added to the execution policy:

logs:PutLogEvents
logs:CreateLogGroup
logs:CreateLogStream

Would you like to continue? [Y/n]: Y
Creating deployment package.
Lambda deploy done.
API Gateway rest API already found.
Deleting root resource id
Done deleting existing resources.
Deploying to: dev
https://xxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/

この時点で上記末尾のURLにアクセスしてみると何やらごちゃごちゃとエラーが表示されますが、これで正常です。

 

3. AWS Lambdaの設定

3-1. Lambdaの設定画面からserverless-health-checker(いつの間にか作成されているはずです)をクリックします。

f:id:phero:20170125213137p:plain

 

3-2. Codeのタブから環境変数(Environment variables)を入力します。

SLACK_CHANNEL 通知する先のSlackのチャネル名。"#"から始めるのと、事前にチャネルを作成しておくことをお忘れなく。
SLACK_WEBHOOK Slack Incoming WebhookのURL
SLACK_USERNAME 任意の名前でOK
S3_CONFIG_KEY_NAME 今回はconfig.ini決め打ちでOK
S3_CONFIG_BUCKET_NAME 上記のconfig.iniを置くS3のバケット名

f:id:phero:20170125213754p:plain

 3-3. TriggersのタブからAdd triggerをクリックし、

f:id:phero:20170125214009p:plain

3-4. CloudWatch Events - Scheduleを選択し、

f:id:phero:20170125214055p:plain

3-5. 死活監視をする間隔(下図の例では1分毎)を入力し、Submitボタンをクリックします。

f:id:phero:20170125214232p:plain

3-6. 最後にSaveボタンをクリックします。(これ忘れがちなので要注意です)

f:id:phero:20170125233322p:plain

 

4. S3へのiniファイルの配置

以下のような内容でconfig.iniというテキストファイルを作成します。

[DEFAULT]
status = 200
timeout = 5 [My Web Site 1]
url = <監視したいURL> [My Web Site 2]
url = <監視したいURL>

それをS3のバケット(S3_CONFIG_BUCKET_NAMEで指定したバケット)にconfig.iniという名前で配置してください。

 

5. S3へのアクセス権限の設定

5-1. IAMの設定ページからロールを確認すると serverless-health-checker というロールがこれまたいつの間にか作成されているので、それをクリックし、

f:id:phero:20170125215958p:plain

5-2. 「ポリシーをアタッチ」のボタンをクリックし、

f:id:phero:20170125220129p:plain

5-3. AmazonS3ReadOnlyAccessを選択し、画面右下の「ポリシーのアタッチ」ボタンをクリック。

f:id:phero:20170125220256p:plain

 

6. 動作確認

さきほどごちゃごちゃとエラーが表示されていた https://xxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/ のページにもう一度アクセスし、先ほどconfig.iniで指定したサイトのURLなどが表示されていれば作業完了です。

 

ためしにconfig.iniの内容を

[DEFAULT]
status = 200
timeout = 5
[My Web Site 1]
url = <監視したいURL>
timeout = 0.001
[My Web Site 2]
url = <監視したいURL>

などと変更し、わざとタイムアウトするようにしてみると、Slackに

f:id:phero:20170125223418p:plain

のようなメッセージが書き込まれるかと思います。

 

というわけで、サーバーレスの死活監視システムの構築方法でした。chaliceとても使いやすくて良いですね。

 

 

2017年年始のご挨拶

明けましておめでとうございます。

 

昨年は子供が保育園に通い始めたこともあり、それなりにバタバタとしていることが多かったような気がしますが、周りの方々のご理解やご協力のおかげで無事に1年を過ごすことができました。皆様には心より御礼申し上げます。

 

また、仕事上でも良い出会いに恵まれ、9月より株式会社クラウドリアルティという会社に勤めているのですが、ここのメンバーがひたすら優秀で個性に富んでおり、楽しく刺激的な日々を送っております。エンジニアやデザイナーを鋭意募集中ですので、一緒に働いてやってもよいぞという方はお気軽にご連絡いただければと思います。

 

それでは、今年もどうぞよろしくお願いいたします。

DjangoからGmail経由でメール送信する際の手順

Python+Djangoでの開発時にプログラムからメールを送信する際に設定すべきことがいくつかあるので、まとめておきます。(ほぼ自分用の備忘録ですが。)

Djangoとか関係なしにプログラムからGmail経由でメールを送信したいだけの方は下記の1と2のみ実施すれば大丈夫です。

 

1. Gmailアカウントを作成(もちろん既存のものでもOK)

これは説明不要なので省略。

 

2. Gmailのセキュリティ関連の設定を変更

(1) Gmailにログインした状態で、画面右上のアカウントアイコンをクリックしてからアカウントをクリック。

(2) ログインとセキュリティをクリック。

(3) 2段階認証プロセスをクリックしてから、有効にします。その際、電話番号を入力してPINコードを受け取る必要があります。

(4) 前の画面( https://myaccount.google.com/security )に戻り、アプリパスワードをクリック。

(5) 端末を選択からその他(名前を入力)を選択し、好きな名称を入力します。

(6) 下記のように16桁のアルファベットが4桁ごとに区切られて表示されているのでこれをメモします。(「メモしたり誰かと共有したりしないでください」とか書いてありますが、もしGoogle先生の言うことを遵守したい方は16桁を暗記してくださいね☆)

f:id:phero:20161026095048p:plain

(7) 動作確認として、以下のコードを実行してみます。

メールが届けば、これでGmail側の設定は完了です。

 

3. settings.pyにメール関連の設定を追加

下記の項目をsettings.pyに追記します。

  

以上でおしまいです。

AutoHotKeyで幸せになれる設定 vol.1

Windowsユーザーを見かける度に「AutoHotKeyいいよ! AutoHotKeyいいよ!」と啓蒙し続けて6年以上が経ちました。非エンジニアの方でAutoHotKeyを愛用してくれるようになった方が1人だけいるのが唯一にして最大の成果です(ちょっと寂しい)。

 

AutoHotKeyとはなんぞや、という方は下記の2つのポストをお暇な時にでも御覧ください。Macユーザーの方はそっとブラウザを閉じるか、AutoHotKeyのソースコードをMacやLinuxに移植して世界をより幸せにする挑戦をするか、お手元のMacを叩き壊してWindowsPCを購入し直すのがおすすめです。

 

 

さて、日々手元のAutoHotKeyのスクリプトを自分好みに改良し続けながら業務を1%ずつ効率化している僕ですが、この度「あぁ、これはなんて便利なんだ!」というショートカットに気付いてしまったので、それをシェアするためだけにこのポストを書いています。

 

その設定がこちらです。

2つの.ahkファイルがありますが、いずれか1つをお好みで採用すれば良いと思います。

 

これは何かというと、「クリップボードに英文がコピーされた状態で【変換キー + T】を押すと、Bing翻訳(あるいはGoogle翻訳)のWebページが開いて日本語の翻訳が見られる」というショートカットです。

 

例えば

AutoHotkey is a free, open source macro-creation and automation software utility that allows users to automate repetitive tasks. It is driven by a custom scripting language that is aimed specifically at providing keyboard shortcuts, otherwise known as hotkeys. 

 という文章がクリップボードにある状態で【変換キー + T】を押すと、Bing翻訳ならこんな画面が表示されます。

f:id:phero:20161005093141p:plain

 

Google翻訳ならこんな感じになります。

f:id:phero:20161005093226p:plain

 

画像中の日本語を読むとわかると思いますが、Bing翻訳がかなり優秀なのでBing翻訳を使うことをおすすめしておきます。

 

これで英語の文章を確認する作業が1%以上効率化できることは間違いないので、興味のある方は是非AutoHotKeyを試してみていただければと思います。

早生まれの子供は人権を侵害されているかもしれない

ちょっと過激なタイトルですが、誇張ではなく本当にそう感じています。なんの話かというと、保育園の話です。


早生まれではない子のことを「遅生まれ」というらしいですが、あまり馴染みがない言葉なので、本記事においては遅生まれの子のことを簡単のために「普通の子」と呼ぶことにします。別に早生まれの子が普通じゃないとは思っていませんので、その点はご了承ください。



さて、普通の子は以下のようなプロセスを経て保育園に入園します。

~ 普通の子の入園プロセス ~

  1. 産まれる。
  2. すくすく育つ。
  3. 次に初めて訪れた4月に保育園に入る。


一方、早生まれの子供は、

~ 早生まれの子の入園プロセス ~

  1. 産まれる。
  2. あっという間に4月が到来するので保育園には入れない。
  3. すくすく育つ。
  4. 翌年の4月に保育園に入る。


というプロセスで入園します。




ほとんどの認可保育園が4月に入園を受け付けるのですが、それまでに早生まれの子供は保育園に預けても大丈夫な状態まで育ちません。保育園によって「満◯ヶ月になっていないと受け入れ不可能」というのが異なり、例えばこんな感じだったりするのですが、まず生後数週間の子供は預けられません。というのも、赤ちゃんというのは産まれて1ヶ月の間はまともに外出すらできなくて、1ヶ月くらい経ってからやっと少しずつ日光を浴びられたり外にベビーカーで連れ出したりできる状態に育っていくものなので、保育園の立場からしても、産まれて3週間しか経ってないような子供を預かるなどというリスクの高いことはやりたくないでしょうし、それは当然のことです。



何が言いたいのかと言うと、つまり早生まれの子は0歳で迎えた4月時点では保育園に入るチャンスが無く、1歳になって迎えた4月に認可保育園にやっと入れる可能性があるということです。


一方、普通の子は0歳で迎えた4月時点で保育園に入れる可能性があり、そこで入れなくても1歳で迎えた4月時点でまた保育園に入れる可能性があるということです。



早生まれになってしまったがために、認可保育園に入園できる機会の数に差が出てしまうのは平等権の侵害ではないのでしょうか?弁護士ドットコムに相談してみようかな…)


うちの子はまさに早生まれで、先日ちょうど全ての認可保育園に断られました。妻は育児休暇中ですが、育児休暇も無限に取れるわけではありません。こんなに子育てがしづらい世の中では安心して子供を産めませんし、少子高齢化の流れから脱することも難しいのではないかと思います。


なお、入園できる機会の数が少ないだけではなく、「1歳児の募集人数は0歳児の募集人数より少なく、しかも応募人数は多い(※)」という状況もあり、不平等に拍車をかけています。(※自治体によりますが)


「4月入園だけではなく10月にも同人数入園できるようにする」とか「入園希望を出すのが初めての子供を優先する」とか、何かしらの対策があっても良いのではないかなと思います。



ちょっと余談にはなりますが、

  • 片親だと入園しやすい
  • 世帯年収が低いと入園しやすい
  • その地域に長く住んでると入園しやすい
  • 共働きだと入園しやすい

とか、色々な変数によって入園のしやすさが変わります(ポイント制になってます)。この中の「世帯年収が低いと入園しやすい(ポイントが高い)」というのもすごく理不尽だと思います。現状、「世帯年収が高い人ほど入園できず、かつ入園できた場合にも保育料が高額になる」のですが、差をつけるのって保育料だけで良くないですかね? 入園できる確率まで下げるのはちょっと酷いんじゃないかなぁと。僕みたいに「年収がズギャーンと下がる転職」をした場合、1年前の世帯年収が判断基準になるので、お金は無いわ保育園入れないわでかなりつらいです。




というわけでまとめると、これから子供を産もうとされている方は是非、

  • 子供が早生まれにならないように計画する・頑張る・運のよさを上げる
  • 子供が産まれる前後に年収を下げるような転職はしない

の2点、くれぐれもお気を付けください。



保育園に入りたい! 2016年版(日経BPムック) (日経BPムック 日経DUALの本)

保育園に入りたい! 2016年版(日経BPムック) (日経BPムック 日経DUALの本)

集合内の任意の2要素の差の二乗の総和

先日、Facebook社が年1回開催しているプログラミングコンテスト(以下、プロコン)である HackerCup というものに参加しました。自分はプロコンガチ勢ではなく趣味でたまに参加する程度なのですが、恥ずかしながらこのHackerCupの存在を今まで知らず、今年初めて参加してみたのでした。


QualificationRound(予選)、Round1,Round2、Round3、FinalRoundと続く中、自分は残念ながらRound2で敗退してしまったのですが、そのRound2で出題された問題の中で使える面白いテクニックを知るにあたりそこはかとなくテンションがあがったので、紹介したいと思います。プロコンガチ勢であれば当たり前のように使っているであろうテクニックらしいですが、自分は今回初めて知ったので、少しでも多くの人にこのテクニックが伝わればいいな、と。またプロコンに興味が無い人が少しでも興味を持ってくれればいいな、と。あるいは世の中に存在する遅いコードが一部でも高速になればいいな、と。そんな思いで書くことにします。(っていうか、珠玉のプログラミングとかハッカーのたのしみとかプログラミングコンテストチャレンジブックとかに書いてありそうな話題ですけど、気にしないことにします。)



では早速ですが問題です。

N個の整数、

 \displaystyle X_1, X_2, X_3, ... X_N

があります。

この中から任意の2つを選ぶ方法は

 \displaystyle \begin{eqnarray}{}_N C _2\end{eqnarray} = \frac{N * (N - 1)}{2}

通りありますが、その全ての選び方で選んだ2つの整数の差の2乗の総和を求めなさい。ただし、総和は相当大きな数値になるので、総和を 1000007(=10^6 + 7)で割った余りを求めなさい。


制限として、各値は

 \displaystyle 2 \leq N \leq 1,000,000

 \displaystyle -100,000,000 \leq X_i \leq 100,000,000 (1 \leq i \leq N)

を満たすものとします。


なお、入力ファイルは、1行目にNの値、2行目からN+1行目にX1からXNが1行に1つずつ記されているものとします。

入力ファイルサンプル1

3
-1
0
1

サンプル1の正解は、 \displaystyle (-1 - 0)^2 + (-1 - 1)^2 + (0 - 1)^2 = 6となります。

入力サンプル2

5
293842
238424
174234
924234
532800

サンプル2の正解は 181270 です。


さて、この時この入力ファイル(サイズ約9MB)に対して正解を求められますか?というのが今回の問題になります。N=1,000,000です。

この問題を見て「あぁアレね」とピンと来ていないエンジニアの方は、是非考えてみてください。多分楽しいので。もしあなたがエンジニアではなければ、身近にいるエンジニアに出題してみるのも面白いかもしれません。




以下、解説です。

続きを読む

開発リソース不足について思うこと

もしあなたがベンチャー企業に勤めているとしたら、まず間違いなく開発リソースが不足していると思います。多くのベンチャー企業において開発者は足りていないはずです。
 
おそらく多くのベンチャー企業というものは、売上が十分あるわけでもなく、資金が潤沢にあるわけでもなく、でも実現したい世界があり、そのために作りたいものがあり、作ったら今度は追加したい機能があり、追加したら今度は改善したい機能があり、また追加したい機能があり、改善したい機能があり、いつのまにか負の遺産があり、それを解決したい欲求があり、そんな中機能追加があり…という感じだと思います。
 
 
 
そんな中、経営陣や開発リーダーが口を揃えて言うのが、この有名なセリフ、
 
「開発リソースが不足しているから、採用を強化しよう!」
 
です。
 
 
 
このセリフ、一見何の問題も無いように聞こえるので異議を唱える人は少ないかもしれません。ですが、開発リソースが不足しているという問題を解決するための手段としては実は危険なのではないかと考えており、警鐘を鳴らす意味でこのポストを書いてみることにしました。
 
 
 
 
 
さて、人手が足りなくなりやすいというのは事実だと思いますが、ではどれくらい人手が足りなくなりやすいのかと言うとこれは自明ではないので、考えてみることにします。
 
 
まず、機能を追加開発することを考えます。機能は時間経過とともにどんどん増えていくもので、経過時間Tに比例して機能数が増えていくとすれば、機能数Nは
    N = aT (aは比例定数)
として表せます。つまり機能の実装にかかる総コストは、機能1つの実装に必要な平均的な開発リソースをFとすれば、
    NF
となります。これをTで微分すると、ある特定の瞬間において機能追加のために必要な開発リソースCが求まり、
    C = dNF/dT = aF
となります。
 
 
また、機能は作っておしまいということはほぼ無く、使われていく間に改善させていかなければなりません。ある特定の瞬間において機能を改善するために必要な開発リソースKはその時点で存在する機能数Nに比例するので、
    K = bN (bは比例定数)
と表せます。
 
 
つまり、ある特定の瞬間において新機能の開発と機能の改善に必要な開発リソースは
    C + K = aF + bN = aF + abT
となります。
 
 
言い換えると、開発開始(≒起業したタイミング)から時刻Tまでに必要な開発リソースは、上記を経過時間Tで積分して
    aFT + abT**2 (**2 は2乗の意)
となるわけです。
 
 
 
 
 
必要な開発リソースの総量の支配項が経過時間Tに比例するのではなく、Tの2乗に比例してしまうんですね。
 
 
 
これはどういうことかと言うと、「経過時間に比例した数の開発者を採用しなければ、開発リソース不足に陥る」ということです。
 
 
 
 
まぁとんでもなく回りくどい言い方をしましたが、簡単に言えば、
  • 機能数に比例した数の開発者が必要
  • 機能数は時間に比例して増える
  • つまり時間に比例した数の開発者が必要
ということです。
 
 
 
 
 
なので、2次関数を知っている人ならすぐに想像できるかと思いますが、あっという間に「やりたいことがたくさんあるのに全然追いつかない」という状況になります。負の遺産を解消する余力なんてあるはずもありません。機能を追加・改善しようと思ったら開発リソース不足になるのが当たり前なのです。
 
 
 
 
 
 
 
 
 
 
 
さて、ここでもう一度この発言を見てみます。
 
「開発リソースが不足しているから、採用を強化しよう!」
 
 
 
ちょっと見え方が変わっていませんか? まるでお風呂の栓を閉めずにお湯を入れている人が「お湯が足りないからバケツでもお湯を入れよう!」と言っているように聞こえませんか?
 
「忙しさの解決のためにはエンジニアを採用すべし」と盲目的に考えてしまうことが危険なことであるというのは経験的にもその通りだと思っていて、そういう状況下でエンジニアを増やして「あ~、忙しさが解消されたわ~。幸せだわ~。」って言ってる人を見たことが無いのですよね。
 
 
 
 
では採用強化じゃない方法で開発リソース不足を補うにはどうすれば良いのか?
 
 
これは上述の方程式の中での仮定のうち1つ以上を覆すしかありません。明示的にあるいは暗黙に何を仮定したかというと、
  • 機能数が時間経過に比例して増える
  • 全ての機能は改善する必要がある
  • 開発者がこなせる作業の量は一定である
  • 経過時間に比例した開発者数の確保は困難である
  • 比例定数aとbが小さくない値である
などです。
 
これらの仮定のいずれかが間違っていると断言することができれば開発リソース不足は解消できる可能性があります。
 
例えば2つ目の仮定が間違っていて、「実は改善する必要のない機能もある」とか。
 
例えば最後の仮定が間違っていて、「実はaとbは限りなく小さい値で、必要な開発者数は確かにTに比例するんだけど、その値が1を超えるのは10年後で、2を超えるのは14年後であるから、この先10年間は開発者は1人だけで十分」とか。
 
 
 
 
 
 
 
私見ではありますが、これらの仮定を覆すための方法が「リーンスタートアップ(機能数を時間経過に比例させず、改善に重きをおく)」だったり、「ピボット(機能を捨てることで、改善すべき機能の数を減らす)」だったり、「めっちゃ売り上げる(そして開発者数を時間に比例させて採用する)」だったりするのかな、と考えています。
 
 
 
 
 
 
僕個人としては、「機能数が時間経過に比例して増える」という仮定を覆すのが良いと考えています。「やるべきことを精査し、やらぬべきことをもっと精査する」というのが開発リソース不足解決のための第一歩で、極限までやるべきことを絞った上でその機能をリーンに改善していく、というのが最良なのではないかな、と。
 
 
もちろん、言うは易し行うは難しではありますが。
 


リーン・スタートアップ

リーン・スタートアップ

  • 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
  • 出版社/メーカー: 日経BP社
  • 発売日: 2012/04/12
  • メディア: 単行本
  • 購入: 24人 クリック: 360回
  • この商品を含むブログ (94件) を見る