メルペイのマイクロ サービスを支える GKE と Cloud Spannerというタイトルで発表してきました。 タイトル通り、GKEやSpannerをどのように活用しているか、などを話しました。
CloudNative Days Tokyo2019で発表しました
メルペイのマイクロサービスの構築と運用というタイトルで発表してきました。
いろいろ苦労しながらなんとかやってますが、まだまだやることはいっぱいあるので興味がある方はご連絡ください!!
追記 ベストスピーカーに選んでいただきました、ありがとうございます!
大変遅くなってしまいましたが #cndt2019 #osdt2019 のアンケート結果より最も得票数が多かったベストスピーカーは @tjun に決まりました🎉 11月の #cndk2019 にもゲスト登壇していただく予定です!!
— CloudNativeDays (@cloudnativedays) August 16, 2019
mercariのtech blog書いた
はじめて投稿しました。
もとは、Microservices PlatformのMeetupで発表した内容です。
本当はもうちょっといろいろ書きたかったのですが、間に合いませんでした。
より詳しい話は、 CloudNative Days TokyoやGoogle Cloud Next Tokyoで発表する予定です、よろしくおねがいします。
Fastly meetup #2でLTしてきた
2019/04/16のFastly Meetup#2 でLTしてきました。枠が余っていたので、2つ。
一つは、Fastlyのメトリクスやログをどのように監視、調査しているかについて、もう一つはKubernetes上のNode.jsのmicroserviceアプリケーション with nginxで画像を配信したときに、404が意図せずFastlyでキャッシュされてしまった問題について話しました。
GAE/Goをdelveでデバッグする
AppEngine/Goでこれまで開発していて、必要な箇所はログを出していれば状態が取れていたのであまりデバッガが使いたくなることがなかったんですが、 最近ちょっとデバッガを使いたい状況があり、AppEngine/Go のローカルサーバに対してDelveをつないでデバッグしたので、やり方を書いておきます。
※基本的に以下はMacでのやり方になります。Linuxもそんなに変わらないと思う。
準備
Delveをインストールします。
go get -u github.com/derekparker/delve/cmd/dlv
GUIを提供する gdlvというのも入れてもいいかもしれません。
サーバを起動
AppEngine/Goのローカルのサーバを立ち上げます。このとき、オプションが必要です。
goapp serve -debug <PATH_TO_YAML_DIR>
または、
dev_appserver.py --go_debugging <PATH_TO_YAML_DIR>
以前は、delveAppengineなどを使う必要があったみたいですが、今はdebug
オプションがあるので不要になりました。
delveをアタッチ
まずアタッチするプロセスのpidを調べます。
$ ps au | grep _go_app 52613 ttys003 0:00.03 /var/folders/wn/xxxxxxxxxxxxxxxxx/T/tmptMHgJNappengine-go-bin/_go_app
アタッチします
dlv attach <pid>
ここは、sudo
が必要かもしれません。
また、自分の環境では MacのOS のversionが古いせいか、以下のようにpathを指定する必要がありました。
dlv attach 52613 /var/folders/wn/xxxxxxxxxxxxxxxxx/T/tmptMHgJNappengine-go-bin/_go_app
delveでデバッグする
あとは、delveでブレークポイント貼ってデバッグしていく感じです。
ここでは解説しませんが、 b
でブレークポイント貼って、c
で回して、n
でステップ実行して、 s
でステップインして、p
で見たい変数見て、l
で今いるところを確認する、くらい知っておけばとりあえず使えると思います。
delve/Documentation/cli
初めて使いましたが gdb
っぽい感じで使えてあまり違和感なかったです。
その他
たぶん設定すればエディタと連携してもっと便利に使えると思います。
以上です。
ドメインをgoogle domainsに移管してみた
きっかけ
放置気味だったDigial OceanからRebootが必要だからバックアップとかしてrebootしろ、という案内が来てた。
Digital Oceanは昔作ったままなのでvagrant
でデプロイするような仕組みになってたし、tjun.org のブログの方は放置してたので、もう全部消そうと決意。
tjun.orgは最近使い慣れているGAEに移す方向で、その際DNSとかも直さなきゃということで、なんとなくGoogle Domainsに移すことにした。
移管の流れ
まずはGoogle Domainsの方で、Transfer Inのところで移管したいドメインを入れてみましょう。 未対応のトップレベルドメイン(jpなど)はGoogleDomainsの方で未対応なので移管できません、と言われます。
次に、転出元(自分の場合はさくらインターネット)で取得してたので、まずそちらで転出の準備をします。 ドメイン管理画面のところから、特に問題なく転出の手続きができました。メールが来るまで2-3日かかったと思います。
この際に、Admin のEmailを自分のemailに直してくれるのですが、GoogleDomainsへの移管の承認には Registrant Emailを自分で受け取って承認する必要があります。(ここがさくらのemailアドレスになっていた) なので、以下の手順で Registrant Emailを変更します。
【JPRS管理】gTLDドメイン 公開情報の変更 – さくらのサポート情報
次に、Google Domainsの方で、Transfer Inのところでドメインを入れて、必要な Auth Codeを入れて、届いた承認メールを確認すれば移管できます。
費用
ちゃんと読んでいなかったけど、 1400円くらいかかりました。 たしか期間を1年延長して移管する、という形になっているので、これは手数料ではなくドメインの更新の費用と思います。ですので、ドメインによって料金は変わります。
特徴など
あまり把握していないですが、以下のような感想です
- WhoIs情報をprivateにすると、名前も含めて保護されるので、安心感ある
- ネームサーバは ns-cloud-*.googledomains.com で、これは Googleの Cloud DNSと同じらしい
- なので、おそらく Cloud DNS相当のパフォーマンスや可用性がある
- DNSSECなども管理画面で設定すれば利用可能なところも Cloud DNSと同等
- 管理画面は、普通に使いやすい
簡単ですが以上です。