コネヒト開発者ブログ

コネヒト開発者ブログ

gdpというGo製のCLIツールを公開しました

f:id:itosho525:20180823212423p:plain

おはようございます。こんにちは。こんばんは。

高校野球が大好きなリードエンジニアの @itosho です。甲子園が終わってしまったので、夏も終わりです。

実は先日ひっそりとGoで書いたCLIツールをOSSとして公開したので、今回はその宣伝をさせていただきます。リポジトリはこちら!

github.com

何が出来るのか?

一言で言うと「tagの作成とリリースノートの作成」が出来ます。はい、それだけです。

tagの作成

tagの作成と言ってしまえばそれだけなのですが、弊社のサーバーサイドのリポジトリはGitHubのmasterブランチにマージされたタイミングでステージング環境にデプロイされる運用になっています。

また、tagがpushされたタイミングで本番環境にデプロイされるようになっており、tag pushがデプロイ戦略において重要な役割を担っています。

もちろん、tagを追加してpushするだけであれば git tag タグ名 して git push origin タグ名 すればよいのですが、上記運用の場合、以下の課題がありました。

  • 意図せずmasterブランチ以外でtag pushしてしまうリスク
  • tag pushするタイミング次第では意図しないものをリリースしてしまうリスク
    • 自分以外の誰かがmasterマージ後にtag pushを行っていない場合など
  • タグ名に指定するバージョンを都度確認するコスト
    • 弊社の場合サーバーサイドのコードは1日に何度もデプロイされるため地味に面倒

gdpでは、上記課題を解決するためにtagの追加とpushをラップしつつ…

  • masterブランチ以外では実行出来ない
  • 事前に今回リリースされる内容を一覧で確認出来る
  • tagを省略した場合は自動で最新のバージョンを付与する

という機能を追加しました。

リリースノートの作成について

元々、弊社ではサーバーサイドのリポジトリに関しては、厳密にリリースノートを管理していませんでした。*1

しかし、人やチームが増え、サービスも大きくなってきたタイミングで、いつ何をリリースしたかを誰でもすぐに簡単に確認出来る仕組みが必要になってきました。

導入当初は CHANGELOG.md に書いていたのですが、ネイティブアプリのリポジトリに関してはGitHubのリリースノートにまとめていたので、これを機に全てのリポジトリのリリースノートをGitHubに統一することにしました。*2

という経緯もあり、gdpではリリースノートをGitHub上に作成出来る機能を追加しました。

どうやって使うのか?

最新の使い方や詳細な仕様はREADMEをご覧いただければと思うので、ここでは基本的な使い方のみ説明させていただきます。

インストール方法

事前にgitとhubコマンドが利用出来るようにしておいてください。

go get またはbrew経由でインストール可能です。

$ go get -u github.com/Connehito/gdp 
$ brew tap Connehito/gdp
$ brew install gdp

tagの作成

gdp deploy が基本コマンドとなります。先述の通り、弊社では tag push=deploy なのでこのようなサブコマンドになっています。

リリースされる内容を事前に確認したい場合

$ gdp deploy -t v1.1.0 -d

tオプションでタグ名を指定して、dオプションをつけるとdry-runモードになります。

実行結果は以下のようになります。

f:id:itosho525:20180823192916p:plain

リリース内容に表示される一覧はmasterブランチへのマージコミットです。

自動でタグを付与したい場合

$ gdp deploy -d

tオプションを省略すると、前回のtagを確認し、自動でtagを付与します。

実行結果は以下のようになります。(前回のtagはv1.0.0)

f:id:itosho525:20180823194100p:plain

実際にデプロイ(tag push)を実行したい場合

$ gdp deploy

dオプションを省略すると、そのまま実行されます。

実行結果は以下のようになります。

f:id:itosho525:20180823195151p:plain

リリースノートの作成

こちらは gdp publish が基本コマンドとなります。利用出来るオプションは gdp deploy と同様です。

$ gdp publish -t v1.0.1

tオプションを省略すると最新のtagからリリースノートを作成します。

実行結果は以下のようになります。

f:id:itosho525:20180823195224p:plain

また、GitHub上では以下のようなリリースノートが作成されます。

f:id:itosho525:20180823195234p:plain

ちなみに

実行後に表示される Do not be satisfied with 'released', let's face user's feedback in sincerity! というメッセージは弊社の開発チームのミッションのひとつである 「デプロイしたで満足せず、利用者のフィードバックに真摯に向き合う。」 の英訳になります。

何故Goで作ったのか?

1年ほど前から個人的にGoは触っていたのですが、それに加え、今年の4月にメルペイさんが主催しているGopher道場に参加させていただき、そこでCLIツールの作り方やテスト技法などを学んだこともあり、今回Goで書くことにしました。

もちろん、これぐらいのコマンドであれば、シェルスクリプトでも書けるのですが、個人としても会社としても言語の選択肢を増やすという点では良い選択だったかなと思っています。

今後に向けて

当初gdpは社内ツールとして使用していたものなのですが、一部機能を改良しCIなどを整備を行い、OSSとして公開出来たこと自体はとてもよかったと思います。

しかし、カバレッジの向上やリリース内容の抽出方法などまだまだ改善すべき点はあります。ですので、それこそ「公開した」で満足しないように、一人でも多くの人に使ってもらえるようなOSSになれるよう今後も継続的に頑張っていきたいと考えています。

使ってみて不具合や使いにくいところがあれば、Issueとして挙げていただければ幸いです。もちろん、Pull Requestも大歓迎です!

注釈

*1:少人数でやっていたこともあり、いつ何をリリースしたかはコミットログを追えば把握出来るため、必要性が高くありませんでした。

*2:これによりRedashを利用して、リポジトリ横断でいつ何をリリースしたかが分かるようになったのですが、こちらについてはまた機会があれば紹介させていただきます。

PHPコードの解析をPhanからPHPStanに移行しようか検討しています

こんにちは、サーバーサイドのお仕事してます金城(@o0h_)です。
7月は「波よ聞いてくれ」と「ベアゲルター」が共に出るという、嬉しい事態でした。沙村作品は魅力的なキャラクターがいつも多いですが、その中でも女性キャラの強さ・芯の太さに圧倒されます。

[まとめ買い] ベアゲルター

さて、今回はタイトルの通り「(静的)解析どうするの」という問題について少し考えている事をまとめてみます。
「Phan」か「PHPStan」か、どっちが良いでしょうか?

https://cdn.mamari.jp/authorized/5b7e38f3-6834-4369-bea6-0018ac120002.jpg

続きを読む

Connehito Marché #3 ~iOS市~ を開催しました!

f:id:kichikuchi:20180821183017j:plain

こんにちは。ママリのiOSアプリを担当している @kichikuchiです。
コネヒトでは定期的に社内のスペースを用いてコネヒトマルシェという勉強会を開催しています。
本ブログにて先日(2018/8/7)実施した第3回目のイベントの様子をご紹介します!

connehito.connpass.com

今回のマルシェのテーマ

今回のテーマは「iOS」です!
コネヒトマルシェは毎回テーマを変えていて、初回がAndroid、前回がwebフロントでした。

LTの様子

アプリの導入画面の実装

簡単まとめ

  • ウォークスルー、コーチマークのライブラリは非常に多い
  • 各種ライブラリを比較した結果自作した
  • そもそも導入画面が本当に必要か?を考える必要がある

Swift5のOwnershipでメモリ効率化

簡単まとめ

  • ownershipはswift5に導入予定
  • メモリ管理をより高度に制御可能になる
  • サーバーサイドswiftや音声処理などの高速な処理が必要なケースで活躍するのでは

swiftの遅延評価について

speakerdeck.com

簡単まとめ

  • swiftの遅延評価にはlazy propertyとlazy collectionがある
  • lazy propertyによりメモリを節約できる
  • lazy collectionによりcpuを節約できる

アプリの開発運用を片手間でするためにすべきたった1個のこと

(資料公開なし)

簡単まとめ

  • DDD(ドキュメント駆動開発)している
  • 率先してドキュメントを書いていたらチームメンバーも書くようになった
  • あらゆることがドキュメントを見ればわかる状態になった結果、新メンバーが入ったタイミングなどの情報共有コストがほぼ0になった
  • Apple Push Notification Authentication Keyとにかく便利なので使ってなかったらすぐ移行するべき

iOS開発からフロントエンド開発に転身

簡単まとめ

  • webフロントは動作確認がとても大変(iOSもそれなりに大変だったけど
  • js/swiftでnull/nilや変数宣言など微妙な違いがありコンテクストスイッチの切り替えが大変
  • 両方できると業務を調整できて便利
  • みんなもフロントエンドやりましょう!!

懇親会の様子

f:id:kichikuchi:20180821181506j:plainf:id:kichikuchi:20180821181523j:plain

今回も美味しいサンドイッチとお酒、各種スナックなどを手に乾杯しました!
懇親会もとても盛り上がり、予定時間よりも大幅におした後の閉幕となりました。

終わりに

f:id:kichikuchi:20180821182002j:plain 台風13号が接近する中での開催となった第3回コネヒトマルシェですが、無事大盛り上がりで終えることができました。
参加してくださった皆さまありがとうございました!!

次回開催の予定はまだありませんが、テーマと日程が決まり次第connpasstwitterにて告知します!

Amazon Auroraの良さについてまとめてみた

こんにちは。インフラエンジニアの永井(shnagai)です。

サービスで使っているDBをRDS for MySQLからAuroraへ移行するプロジェクトを進めていて、 色々と知見が溜まってきたので、これまでAWS SAの方に聞いたりwebで調べたことについてざっとまとめてみました。

アーキテクチャ

リーダエンドポイントによる負荷分散と共有ストレージモデルのメリットが大きい

  • リードレプリカアクセスにLB機能がある
    • リーダエンドポイントによって、ヘルスチェック&ラウンドロビンで読み取りアクセスに負荷分散
    • レプリカ0の場合は、writerにアクセスがいく
    • アプリケーション側のエンドポイントとしては、リーダエンドポイントを指すことでr53では出来なかったヘルスチェック機能付き負荷分散可能(パブリックアクセス許可しないとr53からのヘルスチェックは使えない。。) & HA Proxyやライブラリで行っているLB機能をAWSに任せられる
  • RDS for MySQLだと、Multi-AZ構成で無駄になっていたスタンバイインスタンスがリードレプリカとして使える
  • 共有ストレージモデルなので、レプリカの遅延とほぼ無縁(3AZ 6つのストレージに非同期書込)
  • MySQL5.6互換なので移行にあたりアプリケーションの改修は不要(まだ検証中だが今の所何もなさそう)
  • Auroraインスタンスを束ねるクラスタという概念があるので、クラスタ内のノードの状態について管理する必要がない

運用面

ほぼDBA的な仕事が不要になったり、運用の為の細かい作り込みから開放

  • ストレージ、キャッシュ、DBエンジンが分離されているから再起動が早い
    • DBエンジンの再起動のみなので、Aurora再起動は1分以内で
    • 再起動後のあたため(キャッシュ作り)が不要
  • 暗号化もオプション一つで可能
  • SQLによるフェイルオ−バーテスト(カオスエンジニアリング出来る!!)
    • ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}]
  • 1分でfail over (リードレプリカありのケース)
  • 監査要件で必要とされがちな、AuditLogを有効にした際のパフォーマンス劣化が少ない
    • RDS for MySQLだと1/3ほどになるという話もあったのでサービスで使うインスタンスには使いづらかった
  • ゼロダウンタイムパッチ(ZDP)
    • ダウンタイムゼロでのパッチ適用
    • セッション切断しないのアプリケーションエラーは起きず、5秒ほどのスループット低下のみ
  • DBクローン機能で、本番相当のテストが簡単に出来る
  • バックトラック機能で瞬時に特定時点へのロールバック
    • オペミスしたら瞬時戻すみたいなケースが出来る(もちろん使わないのがベストですがw)
  • ストレージが自動拡張するので、ディスク容量の管理不要(ディスクフルだ。。。からおさらば)
  • コストも下げれる
    • RDSと比べると2,3割高いが、multiAZ構成をはがせるのでその部分でうまくやればコスト削減見込める
  • モニタリングの強化
    • select単位のレイテンシやスループット取れたりCloudWatchで取れるメトリクスがだいぶ増えてる
    • 拡張モニタリングで1s単位でモニタリング出来る

パフォーマンス面

CPUをMySQLよりがっつり使ってスループットを上げるチューニングをしているみたい

ココらへんは、実際に本番の切替を行ってから詳しく見てみる

  • 独自エンジンなので、パフォーマンスアップの為のチューンが諸々あるらしい
    • 独自Cache, Faster index build, Fast DDL
    • 並列度を上げるためのチューンをかなりしてそう??
  • 数%から数10% Disk/IO 性能が高いらしい
  • MySQLと比較すると、統計情報が変わる可能性がある

全体を通じてだいぶ枯れてきている印象で、更新履歴見てもここ2016,2017年で様々なパッチがあたり問題なく運用出来るレベルになっていそうな印象を受けました。

Amazon Aurora MySQL 1.1 データベースエンジンの更新 - Amazon Relational Database Service

来月には、実際のAurora移行プロセスについて書こうと思います。

コネヒトでは、攻めのインフラを一緒に作っていってくれる仲間を募集しています。 少しでも興味ある方いれば是非ご応募ください。

AWSとDockerで600万人の生活を支えるインフラエンジニア募集! - コネヒト株式会社のインフラエンジニア中途の求人 - Wantedly

Greenkeeperでライブラリのアップデートを自動化する

こんにちは。エンジニアの安達 (@ry0_adachi) です、チョコミントが美味しい季節ですね。今回はpackage.jsonとyarn.lockの更新をいい感じで自動化できないかなーと思ってGreenkeeperの検証をしてみたよ、という話です。

Greenkeeperについて

f:id:dachi023:20180624041959j:plain

Greenkeeperはライブラリのアップデートを自動化してくれるGitHub Appです。greenkeeper-lockfileを使うことでyarn.lockにも対応できるとのことなので使ってみることにしました。

競合サービス

Renovateというサービスがあり、こちらもライブラリのアップデートを自動化するためのGitHub Appです。こちらはyarn.lockにデフォルトで対応しており特に設定等は不要そうなのでyarnをお使いの方はこちらの方がいいかもしれません 😇

Renovateについては一休さんの記事がとても参考になりました。

user-first.ikyu.co.jp

料金体系

https://greenkeeper.io/#pricingを見てみると個人とOrganizationのどちらで利用するのかで料金体系が異なり、個人の場合はprivateリポジトリ1個につき$1.5/monthで、Organizationの場合は$25/monthでprivateが10個まで(11個目からは個別に$1.5/month)となっているようです。publicリポジトリはどちらも無料です。

Greenkeeperを使うための準備

CIの設定

  • https://greenkeeper.io/docs.html#prerequisitesに書いてあるようにまずはCIの設定をしておかないといけないです
  • ちなみに1回目にこれを読まずにCI未設定の状態で先にGitHub Appをインストールしたら何も起きなくなってしまいサポートに問い合わせる事になりました 😢
    • 間違えたとしても、GitHub Appを削除→CIの設定をする→再度GitHub Appをインストールでいけるはず、とサポートからは言われました (今回はそれでもダメでしたが...)

GitHub Appをインストールする

  1. https://greenkeeper.io/docs.html#installationあたりを参考にポチポチとやっていきます
  2. 上記手順を2番まで終わらせると「README.mdにGreenkeeperのバッジ追加」と「package.jsonの更新」を含んだPRが作成されます

Greenkeeperが作成したPRをマージする

PRをマージすると初期設定が完了ですが、初回のPRにもpackage.jsonの更新が含まれるのでただしく動作する事は別途確認した方が良いです。

また下記の例だとwebpackが3.xから4.xになってwebpack-cli (もしくはwebpack-command) 入れないとダメになったり、CircleCIで使ってたDocker imageのNodeのバージョンが古くてバージョンアップしたライブラリのenginesの範囲外になってテストがコケました。それくらいだったので手動でサクッと直しましたが、あまりメンテしてなかったリポジトリとかだと最初のPRで地獄を見そうですね。あと、テストがないと動作確認が大変そうです。

Greenkeeperで作成してみたPRの例

f:id:dachi023:20180719192939p:plain

lockfileも更新する

greenkeeper-lockfile を使いましょうということなのでこれをCIに組み込みます。

TravisCIは3行くらいなんで多分サクッと設定できると思います。CircleCIの場合もちょっと書く量が増えますがやってることは変わらないのでWorkflowsがちゃんと分かっていれば大丈夫かなーと思います。

CircleCIのconfig.ymlの例

所感

結論:更新PRを投げて欲しいだけならGreenkeeper、柔軟な設定が必要そうならRenovate

package.jsonとlockfileの更新PRが飛んできてそれをマージするだけなのでめちゃくちゃ楽だなぁ〜と思ったのと、Renovateと比べてやれることは少ないみたいですが、インストール完了までにやることがCIのconfigに書き足すだけなのでシンプルでいいなと思いました。ですが、lockfileがデフォルトで対応されてないのはやっぱりしんどいので改善して欲しいですね...。Greenkeeperの今後のアップデートに期待しつつ、Renovateの動向も追っていきたいなと思います。

社外のエンジニアさんとクローズドなKotlinコントリビュートもくもく会をしてみた

f:id:tommy_kw:20180712131735p:plain

こんにちは

こんにちは、Androidエンジニアの富田です。先日Cluexのアプリエンジニアtakattataさんと一緒にKotlinコントリビュートもくもく会を行い、PRを出すところまでチャレンジしてみましたので内容の共有とKotlinコントリビュートもくもく会の告知をさせていただきます。

takattataさんと始めたきっかけ

僕がKotlinコントリビュートを続けて1年くらい経つのですが、やっと10個くらいマージされたところです。将来的には50、100個とPRをマージされるくらい貢献していきたいですし、さらに「コントリビュートしたい!」と思っている方のサポートをやってみたいと思いつつも、なかなか一歩踏み出せず悶々としていました。そんな時期にtakattataさんの次のツイートを見かけて、「これはご一緒させてもらう良い機会!」と思い、僕から「一緒にKotlinコントリビュートしてみませんか?」とお誘いしたのがもくもく会のきっかけです。急なお誘いにも関わらず参加していただいたtakattataさんに本当に感謝しております。

もくもく内容

先月コネヒトオフィスにて、平日夜の2日に分けて1on1のハンズオン形式で「環境構築」から「サンプルコードのPRを出す」までトライしました。無事作業が終わり、実際に投げてもらったPRは以下の通りですが、僕の調査不足でどうやら既に同様のPRがあったようです...大変失礼しました!!

github.com

本当にざっくりですが作業内容は以下の通りで、ハマるかなと予想していた環境設定も1時間くらいで無事終わりました。ただ思った以上に時間がかかったのが「どのIssueに取り組むべきか」です。これはお互いにYouTrackのIssueを眺めたり、コードを見ながら「サンプルコード提供のIssue」なら短い時間でもなんとかイケそうと考え取り組みました。最終的には合計4時間くらいで環境構築からPRを投げるところまで出来ました。

  • 環境構築
    • Readmeを見ながら環境を設定する
  • YouTrackのアカウント登録
    • Issueを管理しているYouTrackにアカウントを登録する
  • Kotlin Slackの#kontributorsチャンネル設定
  • サンプルコード提供のPRを出す

環境設定でハマったこととして、テストの緑色の実行マークが表示されなかったことです。初日の環境設定では表示されていたのですが...諦めて以下の通りターミナルからGradle経由でテストを動かしました。

./gradlew :kotlin-stdlib:samples:cleanTest :kotlin-stdlib:samples:test --tests "samples.text.Chars"

f:id:tommy_kw:20180712101142p:plain

少しオープンな場へ

クローズドなもくもく会から正式なイベントとしてKotlinコントリビュートもくもく会を開催します! connehito.connpass.com

参加者が集まれば定期的にKotlinコントリビュートもくもく会をやりたいと思います!今回takattataさんと1on1のハンズオン形式でもくもくしてみて、「事前準備が足りなかったな...」、「もっとちゃんと説明できるようにならないとな...」と反省ばかりでしたが、次のtakattataさんのお言葉で継続的にやる!と決心しました。

もちろんIssueの難易度によって異なりますが、PRを投げること自体は大変ではなく、マージされるまでのハードルが高いと課題に感じております。引き続き何か良いアイデアがないか模索していきます。勉強会につきましては嬉しいことにすでに参加枠が埋まっており、もし参加したい方がいらっしゃれば次回も開催しますので、どうぞよろしくお願いします!

コミュニティサービスにおける機械学習のためのアノテーション ~ Annotation Meetupに登壇しました ~ 【資料公開】

f:id:tatsushim:20180706193609j:plain

こんにちは!

CTOの島田(@tatsushim)です。 昨日「Annotation Meetup」に登壇させていただきました。 cloudai.connpass.com 有料(1000円)の勉強会にも関わらず、アノテーションに関心のある方が約50人も集まる会になり、とても盛り上がりを見せていました!

発表資料

私の発表資料はこちらにアップロードさせていただきました。
内容については、ぜひ以下をご覧いただければと思います。

参加して得た学び

最初に登壇のお声がけをいただいたときは、「アノテーション」というテーマでどういう方が集まるのだろう?と思っていました。
実際に懇親会でお話してみると機械学習を活用している方のみならず、アノテーションを受発注されている方もいらっしゃいました。
弊社はアノテーションをすべて自社で行っているので、普段伺うことのできないお話を聞くことができました。

  • 様々なアルゴリズムが提案されているが、多くの場合ラベル付けデータの精度が、学習器の精度を決める要素の大きな割合を占める
  • アノテーションを外注する際にはアノテーターの方を教育して、発注側と受注側で納品されるデータの精度を確認しながら進める
  • アノテーションの際には緊密な課題管理ができるツールを使用する

といった現場のノウハウを伺うことができ、とても興味深かかったです。

終わりに

発表の中で触れているの例のような分類タスクは研究としても前例が少ないです。
加えて、機械学習による事業インパクトを創れることは本当にやりがいがあることだと思っていますので、引き続き機械学習を用いて非連続な成長を創っていきたいと思います!

Annotation Meetup運営の皆様、会場にお越しいただいた皆様、有難うございました。

以上、島田(@tatsushim)がお送りしました!