投稿

RDSのMultiAZについて

Amazon RDS Multi-AZ 配備という公式のドキュメントに書いてあることだが、RDSのインスタンスをMulti-AZ 配備という項目を設定するだけで、簡単にMulti-AZ構成にすることができる。
ただし、DB Instanceが所属するDB Subnet Groupに設定するSubnetが複数AZであることが前提条件である。

今の案件で最初から、DB Subnet Groupに複数AZのSubnetを登録していため、特にはまらずMulti-AZに変更することができた。
単純に可用性を高めたいだけだったので、レプリカインスタンスを作るのではなく、Multi-AZ構成で十分である。

Postfixでsasl_passwdを変更するときの作業メモ

PostfixでSESにリレーしてメールを配信する仕組みを作っている時の作業を忘れがちなため、メモ書きを残す。

sasl_passwdの編集
大体の場合は、/etc/postfix/sasl_passwdにあると思うので、これを適切な内容に変更する。
DBファイルを作成しないと、再起動しても変更が反映されないので注意。

$ sudo vi /etc/postfix/sasl_passwd
Postfixで使うDBファイルの作成
変更した内容に基づいてDBファイルを作成する。
Postfixで使うDBファイルを作成する場合、postmapコマンドを利用する。
これが終わったら、後はPostfixの再起動だけである。

$ sudo postmap /etc/postfix/sasl_passwd
Postfixの再起動
今回は、systemdを利用しているので、systemdでの例を書く。

$ sudo systemctl restart postfix
最後に
何回も同じ作業をやっているのだが、短期間で頻繁に設定することがないため、忘れてしまう。
このあたりの設定もAnsibleでできるようにしておくと捗りそう。

タスクの実行結果をwhenで指定するならcheck_modeつける

Ansibleでコマンドの実行結果をwhenで指定するなら、そのコマンドにcheck_modeをつけよう。
Ansibleの公式ドキュメントに書いてあることだが、cehck_mode: no をつけないと、dryrunでコマンドが実行されずにエラーとなる。
Ansibleのバージョンが2.2未満であれば、alwarys_runというオプションがあるので、そちらを利用する。

どんなケースでエラーになるかというと、

--- - name: 'LANGの確認' shell: localectl status | grep "System Locale" | sed -re "s/.*:\sLANG=//" changed_when: false register: current_lang - name: 'LANGの設定' shell: localectl set-locale LANG={{lang}} when: current_lang.stdout != lang
こんな感じ。
最初のタスクにcheck_mode: noをつければ問題はなくなる。
でも、破壊的な操作につけたら、それはそれで問題になるはずなので、気をつけよう。

ActionMailerで配信前にメールの宛先を変更する

Railsガイドを読んだことある人であれば知っていると思いますが、ActionMailerにはregister_interceptorというメソッドがあり、これに特定のクラスを登録することで、メール配信前のフックを実現することができます。
参考: メールを配信直前に加工する
今回は、それのお話。

配信前に宛先を変更する
Railsガイドに書いてあることと内容が全く同じなので、余り意味がないかもしれません。
基本的には以下のステップで書きます。

フック用のクラスを作成するregister_interceptorにフック用のクラスを渡す
です。

フック用のクラスを作成する
ここでやることは、以下になります。

delivering_emailメソッドを定義するメソッド内で宛先を書き換える
それをまとめると、以下の用になります。

class TestEmailInterceptor def self.delivering_email(message) # クラスメソッドとして定義する message.to = ["test@example.com"] # 宛先を書き換える end end
このようになります。
簡単ですね。

delivering_emailの中では、まだ送信が確定されていないため、色々な加工をすることができます。(後日そのあたりを使った記事を書こうかと)

register_interceptorにフック用のクラスを渡す
ここでやることは、以下になります。

config/initializersに適当なファイルを用意するregister_interceptorの引数に、フック用のクラスを渡す
今回は、config/initializers/test_email_interceptor.rbに定義することにします。

ActionMailer::Base.register_interceptor(TestEmailInterceptor) if Rails.env.test?
のような形です。
最後にifをつけるのかどうかは、どういった処理にしたいかによるかと思います。

最後に
Railsガイドと全く同じと言っても良い記事になってしまいました。
自分のメモ用の記事として書いてみました。
途中でも書いた通り、後日今回のフックでメールのちょっと…

ElasticIPを複数利用する時の注意

今の案件で、複数のElasticIPを利用しようと思った時のメモ。

ElasticIPが確保できない?
Terraformを利用してAWS上のリソースを管理しているのだが、terraform applyが失敗したのである。
その時のエラーの一部を抜粋したの以下。

Error creating EIP: AddressLimitExceeded: The maximum number of addresses has been reached.
どうやら上限に達してしまったらしい。
公式ドキュメントに書いてあるのだが、デフォルトのElasticIPの上限は5である。
すでに5個のIPを利用してしまっていたので、この制限にひっかかってしまった。

もし制限を緩和したい時は、AWSのサポートセンターにケースを作成して、問い合わせよう。

人を動かすを読んで

帰省中に読んだ本の中野1冊である人を動かすを読んだ感想です。

人を動かす
この本は、アメリカ出身のデール・カーネギー氏の著書です。
割りと有名な本だとは思いますが、今回は自分の行動を振り返るという意味で読み始めました。

人を動かす三原則人に好かれる六原則人を説得する十二原則人を変える九原則
といったように、章立てされています。
内容については省きますが、要は「相手の立場になって考える」ということになります。
本の中では、著名な方や一般の人達の多くのエピソードが載っています。
その中で、「彼らは何故成功したのか」といった観点で本が進んでいくように思えます。
「自分がこうされたら、嬉しいか?」と考えながら、読み進めていくとするすると、入ってくると思います。
実践しようとしても、中々難しいことがあります。
自分が育ってきた環境や、現在の性格などで、簡単に変えることはできませんし、忍耐が足りずにボロが出てしまうことでしょう。
だからこそ、今の自分に足りない人間的な部分の目標が出来ました。

人を動かせるか
それは無理だと思います。
本の序盤で出てくるエピソードで、人の心理は分からないということを書いています。
だから確実にできるとは言えないと思います。
また、ここに書かれているエピソードを元にして、悪用することもできるかもしれません。
この本では、そういった事を伝えたいのではなく、心の底から態度を変える必要があるということなのでしょう。
そうすれば、見える世界も、周りの環境も変わります。と。

この本は、定期的に読み直して、日頃の自分の立ち振舞を改善していきたいです。

EC2にNameをつける

AWSを利用している方なら基本中の基本だと思いますが、EC2の管理画面を見ているとNameという列があり、Terraformで作成していると空になっています。
これは何故でしょうか?

TL;DR
Nameタグを設定すれば表示される。
何故、表示されないのか?
AWSの公式ドキュメントであるAmazon EC2 リソースにタグを付ける - Amazon Elastic Compute Cloudに書いてある通り、キーがNameのタグの値に名前を入れれば、表示されます。
つまり、Nameタグが未設定なだけだったのです。
以下が当時書いていたtfファイルです。

resource "aws_instance" "khasegawa" { ami = "${data.aws_ami.image_id}" instance_type = "${var.instance_type}" disable_api_termination = false subnet_id = "${aws_subnet.khasegawa.id}" tags { Administrator = "${var.email}" Environment = "${var.environment}" } lifecycle { "ignore_changes" = ["ami"] } }
tagsに見事にNameを書いてませんね。

Nameタグを設定しよう
Nameタグを設定した方がEC2インタンスだけでなく、他のAWSリソースでも判別しやすくなります。
適切な名前を設定をしましょう。
先程のtfファイルに追記すると、こうなります。

resource "aws_instance" "khasegawa" { ami = "${data.aws_ami.image_id}" instance…

Nginxでメンテナンスページを表示する

Nginxでメンテナンスページを表示させる仕組みを作った時の覚書。

環境
Nginx ... 1.12.2
やりたいこと
今回、メンテナンスページを表示させるに当たって、前提条件・実現したいことをまとめます。

前提条件
Nginxのrootに指定してあるディレクトリにmaintenance.hmtlというメンテンナンスページ用のページを用意している
実現したいこと
メンテナンス画面への切り替えで、Nginxの再起動を必要としないメンテナンス中は、Webアプリと通信しないメンテナンス中に/health_checkへのリクエストが来た場合、200で空のレスポンスを返す/health_check以外へのリクエストの場合は、メンテナンスページを表示させるメンテナンスページのHTTPステータスコードは503にする
これらを実現したいのです。

やってみる。
Nginxでは、ifの中に複数条件が書けないですし、ifの中にifを書くことも出来ません。
どういうことかというと、メンテナンス中かつ/health_checkへのリクエストであるをifの条件式に書くことが出来ません。
そのため、無理やりですが以下のように書きました。

error_page 503 @maintenance; # Maintenance set $maintenance false; set $maintenance_app_request false; set $maintenance_health_check_request false; if (/usr/src/app/tmp/maintenance.txt) { set $maintenance true; } if ($request_uri ~ ^/health_check) { set $maintenance_health_check_request $maintenance; } if ($request_uri !~ ^/health_check) { set $maintenance_app_request $maintenance; } if ($maintenance_app_request = true) { return 503; } location @maintenance { try_fil…

伝わっているか?を読んで

帰省中に読んだ本の中の1冊である伝わっているか?を読んだ感想です。

伝わっているか?
この本は、問題に困っている人に対し、イルカが助言を与えたり、一緒に考えていくスタイルの本でした。
それぞれの問題に関しては、会社員として働いてる方なら起こりそうな話題や、ちょっと変わったものまでありました。
どの問題も、普段からしている言い方や考え方もあれば、「そういう考え方もあるのか!」と納得するような問題もありました。
これらは、著者である小西利行氏が、長年コピーライターとして培ってきた知恵なんだと思います。
この知恵が価値があるかないかは、読んでみないことには判断しづらいです。
私が読んでも、「それはそうだよね」って思うようなこともありました。
それと同時に、読む前の私には出来ない考え方もありました。
だからこそ、人によっては全て当たり前のようなことかもしれません。
そういった方からしたら、価値は余りないと思います。

伝え方って大事ですよね
伝え方って大事ですよね。

友人、恋愛、親類、仕事。

どれをとっても、伝え方1つで印象が大きく変わります。
一歩下がって考えてみると見えてくるものもあります。
例え仕事に対し真面目であっても、伝え方が下手だったら、中々評価が上がらないし、場合によっては怒られてしまう世の中だとは思います。
それは私自信への戒めでもあり、就活している方たちや、すでに就職している方、フリーランスをやっている方にも一読してもらいたいなと思います。
まだ高校生の方だとしても、どこかで役に立つかもしれません。

世の中は理不尽です。
その理不尽の中で、どうすれば良いのか、考えさせられるような1冊でした。
自分の不幸や不運を嘆くことは簡単に出来ます。
が、それにどういう形であれ向き合うことは難しいことです。
そういった時は一旦落ち着いて、「伝わっているのか?」と、自問してみるのもいいですね。

その他にも、デール・カーネギー氏の人を動かすという本を手にとってみるのも面白いかもしれません。

来年の抱負

今日で2017年も終わりです。
今年は、自律神経失調症で休職したり、思ったように仕事が出来なかったりと、個人的には辛い1年でした。
大晦日に、何か書くような気力は残ってないんですが、来年の豊富だけ書いておこうかなと。

自己の体調管理を見直す(良くはなりつつあるんですが、まだまだ万全とは言い難い)日々の学びをアウトプットする(ブログでも、勉強会でも)自分で今までやってきたこと、自分が持っている知識・技術などを上手くアウトプット出来ていない気がするので、来年の目標にしようかなと。

Macにプリインストールされているrsync

Macにプリインストールされているrsyncを使って、リモートのホストへファイルを同期している時に起きた問題です。

TL;DR
Macにプリインストールされてるrsyncは2.6.92.6.9だとiconvオプション使えないので、ファイル名が文字化けしたり、エラーになるHomebrewでインストールしたrsyncを使うか、ファイル名に日本語入れないで
環境
MacOS ... 10.12.6rsync ... 2.6.9
invalid byte sequence in UTF-8
MacOS上でリモートにファイルを同期しようとしたら、突如エラーが出ました。
invalid byte sequence in UTF-8 何とも悲しいメッセージです。
まさかと思い、ファイル名をリストにしてみると...
ファイル名に日本語が含まれているファイルがありました。

rsync2.6.9だとiconvオプションもないし、文字化けすると聞きました。
Homebrewでrsyncをインストールして、そちらを使うようにしてみます。

Homebrewでrsyncをインストール
特に難しいこともないです。
最新のrsyncをインストールしましょう。

$ brew install rsync $ rsync --version rsync version 3.1.2 protocol version 31 Copyright (C) 1996-2015 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes, no prealloc, file-flags rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welco…

サービスイン前ならDNSレコードのTTL短くしとく

サービスを作る時にドメインを取得し、そのドメインのDNSレコードを設定しますよね。
会社で先輩から言われたことでもあるんですが、サービスイン前ならTTLを短くしておいた方が良いです。

TL;DR
サービスイン前は、TTLを短くするサービスイン後は、TTLをある程度長くしておく
TTLを短くする
サービスイン前に限定して話ですが、AWSなどといったサービスを利用していると、頻繁にインスタンスが変わったり、AレコードなどといったDNSレコードの設定を変更する時ありますよね。
そういった時にTTLが長いとどうでしょうか?
中々が変更が更新されずに、開発や環境構築のペースが落ちてしまいます。

NSレコードは5~10分、Aレコードなどは1分あたりで良いです。

サービスイン後は?
サービスイン後は、短くする理由は基本的にはないです。
何故なら、TTLを短く設定している時のメリットよりも、デメリットの方が大きいからです。
どんなデメリットが考えられるでしょうか?

DNSキャッシュポイズニングの危険性DNSサーバーへの負荷が上がる
パッと出てくるのは、この2つです。

DNSキャッシュポイズニングの危険性
ここでは、DNSキャッシュポイズニングの具体的な流れについては触れませんが、TTLが短い場合は、この攻撃を遂行しやすくなります。
TTLを長くすることで、その危険性をある程度は下げることが可能です。

DNSサーバーへの負荷が上がる
TTLが短いと、エンドユーザー側の端末でもキャッシュの期限が切れ、短い間隔でDNSサーバーに対してリクエストされるようになります。
となると、DNSサーバー側はどうでしょうか?
多少リクエスト増えたぐらいでどうにかなるものではないですが、負荷が上がってしまうことが容易に考えられます。
多くの人達に使ってもらうサービスなら、こういった細かい点を、どこかのタイミングで考えれると良いですね。

最後に
確かにサービスイン前だと、早く変わってもらわないと困る時が多々あるので、TTLを短くしておくのが嬉しいですね。
短くしたら、サービスイン前後で設定を見直すことを忘れないようにしましょう。
サービスイン後には、NSレコードは1日程度にしておくのが良いです。(割りと一般的らしい)

データへアクセスさせるなら必ず対策をしよう

つい先日、特定のテーブルのレコードが全削除されるような事件を、初めて目の当たりにしました。(私が関わってるわけでない)
そこで再確認できたことは、アクセス権を渡すなら権限を絞ることの重要さでした。

実際にあった話を書くわけにもいかないので、その話をベースに若干変更したフィクションです。

何が起きたのかあるシステムのDBに、関連会社のAさんが作業上、ツールなどを介して直接アクセスする必要がありました。
その作業では、データの確認や修正があったことは言うまでもありません。

ある日、Aさんはツールで操作を誤ってしまい、あるテーブルの全レコードを削除してしまったのでした。
要は、DELETE FROM table_name;が発行されたということです。

何故、起きたのか当事者では、ないので想像で語るしか出来ません。
その想像を語る価値もないので、皆さんのご想像にお任せします。

どれだけの問題なの?データや復旧の可不可によって、レベルが変わります。
NetflixやHulu、dTVなどといったVODサービスを想像してみてください。
VODサービスには、動画のようにサービス提供に必要なコンテンツや、ユーザーの決済情報や連絡先などを保持する会員情報、各ユーザーの視聴履歴などの履歴データなどが保存されると考えられます。

例えば、コンテンツが削除されてしまった場合はどうでしょうか?
コンテンツは、VODサービスにとってはサービスそのものです。
これが削除されるということは、サービスが停止し、解約の危険や競合のサービスへの顧客流出などが考えられます。
皆さんは色んなサービスを利用していると思うので、これが1,2時間程度でなら許せる方もいるでしょう。
もし、バックアップなどがなく、復旧できない状態だったらどうなるでしょうか?
これは言うまでもなく分かりますよね。

会員情報についても同様です。
軸は違いますが、これも相当というか、会員系サービスの場合は致命的過ぎます。
「決済系の情報が操作ミスで消えました」と言われたら、あなたはそのサービスを利用し続けようと思いますか?

最後に履歴データですが、視聴履歴などといった情報も重要なことには重要ですが、その情報をサービスの根幹にしてない限りは、サービスは継続可能でしょう。
もちろん、顧客流出はあります。
が、上2つの例とは比較にならないです。

例とし…

ブログ用のMarkdown変換ツール

このブログはBloggerで書いてるんですが、下書きはMarkdownで書いています。
となると、HTMLに変換するツールが必要になります。
専用のコマンドラインツールを用意しているんですが微妙だったので、ウェブアプリとして作り直しました。

Markdown to HTMLMarkdown to HTMLというのを、herokuで動かしています。
自分でパーサーなどを作っているわけではないので、技術的には面白みがないです。
md2htmlというリポジトリにコードは公開してあります。
<p>タグで囲いたくない(囲わなくていい設定にしてる)ので、こういうツールを作ったんですねー。

最後にJSのライブラリもあるので、ここまでやる必要もなかった気がしますが、今回は普段使い慣れてるRubyでさっと書きました。
他にもこういうツールを、作っては捨て、作っては捨てしてるので、ある程度は残していこうかなと思いました。

入社してから今までを振り返って

私は、今の会社に2014年4月に新卒入社しました
2016年春頃(3年目になる直前ぐらいかな)に、大規模案件の開発リーダーをやることになりました。
そして、2017年2月~3月末の約2ヶ月間、休職することになりました。
今は復職し、小規模なチームの開発リーダーをやっています。
それらを振り返ってみようと思います。

入社1年目 2014/04~2015/03全然覚えてないです。
ただただがむしゃらに技術書を読み漁り、プライベートでも休憩中だろうと、ひたすらコードを書いていました。
それだけは覚えています。

入社2年目 2015/04~2016/03この歳は、良くも悪くも覚えています。
当時付き合ってた方と別れ、その後ドイツから同年代のインターンシップ生が来て友人になり、年度末には開発リーダーになりました。
その方には迷惑をかけてしまいました。
謝りきれないぐらいに。
ドイツからきたインターンシップ生は、ほぼ同年代だったので、一緒に帰ってMac行ったり、ダベったりしてました。
当時、恋人いなかったので、そのことにちょいちょいつつかれたの覚えてるからな!
彼とは頻繁ではないですが、未だにメールする仲です。
年賀状送り忘れて本当にごめん。
開発リーダーに抜擢されたという表現は合ってないと思います。
そのため、敢えて「なりました」という表現にしました。
人手不足の兆候だったと捉えるべきでした。
開発リーダーになれたことに誇りに思いますし、選んでくれた人達には感謝しています。
ただ、最初の案件としては俺には大きすぎたかな。

入社3年目 2016/04~2017/01開発リーダーをやっていた期間ですね。
この期間も余り覚えてないですが、補助してくれた先輩や、間に入ってくれた先輩たちのおかげもあって、余り負担がなかったように思っていました。
この時期もがむしゃらに自分の出来ることを、ひたすらやっていただけです。
そのがむしゃらが良くなかったのかもしれません。
2年目で恋人と別れてしまって、ちょっとした自暴自棄になっていたのかもしれません。
自分の身を大切にしないような行動ばかりしていました。
ただただ負担をかけて、自分を追い込んで。
それが結果として自律神経失調症となって、休職するきっかけになったのは言うまでもないです。
当時の関係者の方々には謝っても謝りきれないです。
この案件が具体…