NRUG (New Relic User Group) SRE支部 Vol.1 「俺たちのSREとNew Relic」に登壇しました!

こんにちわ! CTO室でSREやっている@Tocyukiです!

先日、5/13にNRUG (New Relic User Group) SRE支部の記念すべき第一回目のイベントに登壇したので、参加した経緯とか振り返りをしていきたいと思います💪

nrug-sre.connpass.com

そもそもなんで登壇したの?

実はこのNRUG SRE支部には運営として携わっているのですが、たしかTwitter上でSRE支部設立の機運が高まり、そのやりとりに反応したらNRUGのSlackでNew Relicの中の人からメンションが飛んできてそのまま運営メンバーになっていた、という感じですw

SRE支部設立の瞬間

そんなこんなでとりあえず運営メンバーになり、最初のイベントということで週次でMTGしながら案出しは色々していたんですが、運営の3名がそれぞれフェーズも規模も異なる組織でSREをやっているということで、まずはそれぞれの「俺たちのSREとNew Relic」とかでセッションするのが良いのでは?という流れでイベントタイトルおよび内容が決まりました。

なんで運営に参加しようと思ったの?

自分は今までこういったイベントや勉強会には参加するだけで、運営に携わったこととかはなかったのですが、単純に他社のSREの方と繋がりたいなぁ、というのとすでに弊社で導入しているNew Relicへの興味、知見を高められると良いなぁと思ったのに加え、弊社の開発組織フェーズ的にも社内外へのポジティブな影響が期待できるんじゃないか?との思いで参加しようと思いました。

採用的な部分や社内へもポジティブな影響を及ぼせるだろうという思いはありましたが、外部コミュニティでの活動が自身と社内外へどのような影響を及ぼすのか、という部分について実際に確かめたくなったという側面もあります。

やってみてどうだったか?

これはもう本当にやって良かったです👌

今までの自分の経験やナレッジの有効性や需要的な部分の反応は自分の影響が及ぶ範囲でしか確認することができなかったのですが、今回運営でのMTGや登壇を通して、とてもポジティブな反応を頂けたので、自分がやってきたことに自信を持てるようになりました😎

あと、単純にポジティブな反応がもらえるのはとてもモチベーションに繋がりますし、嬉しいですw

特に今回のイベントはアンケートの回答率が30%近くあり、かなり満足度が高かったようで、そのようなイベントの運営に携われて本当に良かったです。

これからも積極的に自身でやってきたことをアウトプットしていき、どのような反応がもらえるか、またどのような影響が出るかを楽しみながら、社外のエンジニアの方との繋がりを増やしていけると良いなぁと思っております!

おわりに

情報は発信する人に集まるという性質もあるのかなと思いますので、モチベーション旺盛なエンジニア諸氏におかれましても積極的にコミュニティ活動や登壇等チャレンジしてみると良いのではないでしょうか?

そしてイベントが盛り上がったということでNew RelicさんにLPと開催レポートを作成していただきました!

こちらからイベントの動画や登壇資料も確認できますので是非ご確認くださいー👍 newrelic.com

開催レポートはこちら

newrelic.com

NRUGのSlackも誰でも入れますので、New Relic気になってる方は是非参加してみてください! join.slack.com

あと今回Twitterも非常に盛り上がったのでTogetterにもまとめたのでこちらも👍 togetter.com

そしてそして弊社トラストバンクでは様々な職種で絶賛採用中なので気になった方は是非お気軽にご連絡くださいー!

www.wantedly.com

リモートワークだからこそ取り入れたい!スウェーデンの雑談文化「Fika」のススメ

こんにちは!パブリテック事業部でSREを担当している藤谷です。前職でスウェーデン人と仕事をしていた時に教えてもらったスウェーデンの文化「Fika(フィーカ)」を紹介します。 トラストバンクでは原則リモートワークで、工夫をしないとチーム内でのコミュニケーションが取れないこともしばしばあります。 そんな中、実際にパブリテック内でもFikaを実践し始めています。

Fikaとは?

一言で表すと「コーヒーブレイク」です。 スウェーデンではFikaという習慣が根付いていて、どんなに忙しくても一旦仕事の手をすべて止め、コーヒーを飲みながら甘いものを取り入れる時間を一日数回、15分程度設けられています。

語源は音節が逆になる倒語で、スウェーデン語のコーヒー「kaff」がFikaと呼ばれるようになったと言われています。 スウェーデンではFikaが行われる職業は限られておらず、公務員もFikaの習慣が根付いています。 時間は人それぞれかと思いますが、一般的には毎日10時頃と15時頃にFikaの時間を設けることが多いそうです。

Fikaのやり方

雑談相手は誰でも良いです。(同僚、上司、部下等)作業の手を止め、仕事のことは忘れて、15分程度コーヒーとスイーツを食べながら雑談するだけです。 もちろん、コーヒーの代わりにお茶でもホットココアでも良いですし、スイーツが苦手なら、サンドイッチのような軽食でもいい。場所、時間や相手など、基本は自由です。

Fikaの3つのメリット

①仕事にメリハリが生まれる

仕事が忙しいと休み時間を割いてでも、仕事をしてしまいがちです。 ですが、人間の集中力が続くのは60分、長くても90分が限界だと言われています。 長く続けてしまうと疲労が溜まってしまい、その状態で無理やり仕事を続けると効率が落ちるだけでなくミスの原因になります。

筋トレなどの運動も一緒で、適度に休憩を挟まないと長くは続けられないのと同じです。

スウェーデンのFikaは習慣として根付いているため、ほぼ強制的なコーヒータイムです。 一旦すべての仕事から手を離れ、Fikaタイムを取ることで仕事にメリハリが生まれ、短時間でも作業が進み、効率よく質の高い仕事につながります。

きわめて能率がいい社員の働き方

「SINGLE TASK 一点集中術――「シングルタスクの原則」ですべての成果が最大になる」という書籍にも以下のように書かれていました。

  • 能率がいい社員は、出社後すぐに仕事に取りかかるうえ、1日のあいだに何度か休憩時間を設けている。
  • 日々のスケジュールにリフレッシュする時間を組み込むことで、能率を上げている。
  • そのうえ、彼らは昼食時にも一切仕事しないことを心掛けている
  • 〈休憩を定期的にとるほうが、かえって成果をあげられる〉
  • しっかりと休憩し、自分を「オフ」にする時間があるからこそ、「オン」のときに集中できる。

②仕事にメリハリが生まれた結果ストレスフリーな働き方になる

  • スウェーデンでは、夜遅くまで会社に残ることは美徳とされていなく、愛する家族や自分の生活を大切にしているため、定時ダッシュするのが基本中の基本のようです。
  • Fikaは作業の手を止めて息抜きする時間なので、一旦仕事はすべて忘れ、休むときはしっかり休んで、働くときは集中して働く。メリハリをつけて取り組んだ方が、生産性があがるとスウェーデンでは言われています。

③仲間と雑談することでコミュニケーションが活性化される

  • Fikaは単なる休憩ではなく、非常に重要なコミュニケーションのきっかけとして重視されています。意識的に時間を取って、同じ時間に仕事の同僚等とコーヒーやお菓子を食べながら雑談をしたり、週末の予定を立てたりして会話を楽しむこと。
  • それによって職場での意思疎通が進んだり、意見を自由に言える雰囲気が出るなどのメリットがあります。
  • 仕事をするときはとことん打ち込んで、ちょっと疲れたころに甘い物で元気をチャージ。リラックスしながらおしゃべりすることによって社内の空気もよくなり、コミュニケーションの活性化も望めます。
  • 話のトピックは人によってさまざま。天気の話題にとどまらず、趣味やペットのことなどを、アットホームな環境でのんびり語り合う。そうすることにより、チーム全体の連帯感も自然に強まっていくらしいです。

まとめ

リモートワークではコミュニケーションが希薄になりがちです。雑談の文化としてFikaが習慣として根付いているスウェーデンの働き方は参考にできるところが多くありました。 Fikaは仕事の効率のためだけではありません。雑談のきっかけとして、実践してみませんか?

トラストバンクではエンジニアを募集しております! ポジションにとらわれず、いろいろなチャレンジができますのでご興味ありましたら是非募集ページをご覧ください! www.wantedly.com

Sentry運用日記 - 検知されるエラーをbeforeSendでフィルタリングする

どうも、フロントエンドエンジニアの田口です。
以前Sentryについての記事を書いたのですが、導入してから運用として問題が出てきたので、その対処をしたという続編みたいなものになります。
Sentryについては「導入した!」という記事は多いのですが、その後の運用についてはあまり語られていないような気がしますので、導入したばかりや導入を検討中という方の参考になればという期待を込めて書かせていただきました。

前回↓
tech.trustbank.co.jp

前回のあらすじ

クライアントサイドでのエラー検知のためにSentryを導入した

Issue多すぎ問題

Sentryの導入時、エラーがどれほどの量検知されるのか、また導入によるデメリットなどは無いかの確認のため、いきなりサービスの全ページを監視するのではなく、監視範囲を徐々に広げていくような導入方法を採りました。最初はユーザーの訪問数も少なめなページで様子を見て、その後は訪問数の多いページを少しずつ監視対象として追加していき、最終的に全ページを監視対象としました。
しかし、訪問数の多いページを追加監視していくのに比例して、明らかにエラー検知数が増加しており、3月期にはTeam Planについてくるエラー検知クォータ(5万イベント)を25日目にはオーバーし、クォータを追加することになりました。
導入によるデメリットもなく、エラー検知のメリットを感じ始めていたことを踏まえ、監視対象の拡大は進める一方で、多すぎるIssueによりトリアージの判断も困難になってしまっていたため、増えすぎた検知数をなんとかする必要性も高まりました。

対処しなくて良いエラー、対処すべきエラーの見極め

そもそもどんなエラーが増えているのかを確認するため、加速度的に増えていくIssuesの件数にツラさを覚えつつも、検知数の多いIssueから分析を開始しました。
これは普通のエラーですね。エラーの原因も分析が可能ですし、解消も容易です。

画像はイメージです

一方でこのようなエラーも。

これは……?

最初のエラーと比較してみるとstack traceが何も出ていません。このIssueの内容から原因を調査して対処するのはかなり厳しいものがあります。 *1
ツラいことに、こうしたIssueの数は分析可能なものと比較しても同じかそれ以上の量上がってきていました。エラーのトリアージ(優先度付け)として、このような分析困難なエラーに向き合うことは時間やSentryのクォータを丸々含めた「予算」の無駄になりますので、フィルタリングすることにしました。

フィルタリング方法の検討と実装

フィルタリング方法で最も簡単なのは管理画面で捨てたいものをポチポチとやればすぐに捨てられる方法ですが、果たしてSentryにあるのか…と思ったら、ありました。

削除しつつ将来にわたり無視する…完璧だ

しかしこの無視する機能、Teamプランでは使用できません。一つ上のBusinessプランが必要です。残念ですがこちらの使用は断念。
ということで管理画面からのフィルタリングはTeamプランではほとんど出来ないので、SDKによるフィルタリングを実装しました。

beforeSendという強力な味方

Sentry SDKには便利なオプションがいくつもあり*2、既にwhiteListUrls(allowUrls)によるURLでのフィルタリングやenvironmentによるIssueのタグ付けを導入していました。
今回のフィルタリングでは、beforeSendを使用しました。beforeSendは関数を登録でき、eventオブジェクトを返せばエラーをSentryに送り、nullを返せばエラーはSentryに送られずに破棄されます。
例えばstack traceの有無のみでフィルタリングするのであれば以下のような簡単な実装で済ませられます。

beforeSend(event) {
  try {
    const hasStacktrace = event.exception.values.some(value => {
      return value.stacktrace?.frames?.length > 0;
    });
    if (hasStacktrace) {
      return event;
    }
    return null;
  } catch {
    return event;
  }
}

beforeSendはかなり柔軟な実装ができますので、エラーに関する情報が詰まっている引数のeventの中身を一度確認してみることをおすすめします。
また上のスニペット例では引数としてeventしか使用していませんが、第二引数としてhintが使用可能です。
hintオブジェクトにはoriginalExceptionというプロパティがあり、Sentry特有のエラーのオブジェクトに変換される前のエラーが取得できます。が、内容的にはeventオブジェクトでも取得可能なもののようなので、今のところhintは使用していません。

Sentryの公式ドキュメントでもbeforeSendをはじめとするフィルタリングのアイデアがいくつか書かれていますので、こちらを見ながらサービスに必要なフィルタリングを実装していくのがGoodかと思います。

docs.sentry.io

Sentryの運用はフィルタリングが肝

beforeSendによるフィルタリングによって、上がってくるIssueのほとんどは分析可能なものになりました。数は多いのですが、これらは一つ一つバグとして潰していくことが可能です。
Sentryの運用をされている方の記事等を見ているとフィルタリングの重要性について書かれていることが多いので、重要性を認識してはいたのですが、今回の改善によってより一層認識を強くしました。
今後はSentryでバグを潰していくとともに、Sentry自体の運用についても定期的に見直していこうと思います。またアップデートをしたときにはここで記事を書きます。

それでは今回はこの辺で〜ノシ

ということでいつもの

トラストバンクではバグを分析し、それを修正することが得意なエンジニアを随時募集しております! www.wantedly.com

*1:ちなみにこのエラーについて調べたところ、マーケティング関連のタグ(GTMか何かで導入されている)でfetchで取得したいリソースがCORSエラーになっていたようです。allowUrlsでファイルのパスでフィルタリングしているのにIssueとして上がってしまう理由は分かっていません😓

*2:https://docs.sentry.io/platforms/javascript/configuration/options/

CloudflareでTorをブロックする方法

パブリテック事業部のSREを担当している大場です。

突然ですが、Torネットワークというのをご存じでしょうか?
秘匿性の高い通信を行う際に利用される技術ですが、検索するとダークウェブなど何やら怪しい言葉が並びます…。あまり一般的に利用されているものではありませんが、Torブラウザを使えばだれでも利用はできます。
このようにいろいろな国を経由してアクセスしているようです。
f:id:hideki_oba:20220407180616p:plain

少しだけ紹介しましたが、Torブラウザの利用を推奨しているわけでは決してありません!

で、本題ですが、、
リスク軽減かつ、あまり利用ケースも考えられないため、TorネットワークからLoGoフォームへのアクセスをブロックすることにしました。
大げさにきこえるかもしれませんが、LoGoフォームではCloudflareを利用しているので設定はめっちゃ簡単です。
f:id:hideki_oba:20220407181043p:plain

ファイアウォールルールでこの設定をするだけです!超簡単ですね。

Cloudflareに感謝しつつ、トラストバンクではエンジニアを募集しております!
ポジションにとらわれず、いろいろなチャレンジができますのでご興味ありましたら是非募集ページをご覧ください! www.wantedly.com

Chromeのタブを自動クローズ!拡張機能xTabが作業効率UPに役立つ3つのポイント

f:id:tb_hiromu_fujitani:20220405091429p:plain こんにちは!パブリテック事業部でSREを担当している藤谷です。 去年まではタブを開きすぎてしまうことが多かったのですが、半年ぐらい利用しているGoogle Chrome拡張機能「xTab」が作業効率UPに役立っているので、そのポイントを3つ紹介します。

ブラウザのタブ、気付いたらこんな状態になっていませんか? もしなっている場合は、今回紹介する「xTab」を使うことで強制的にタブを開きすぎてしまうクセを改善し、それによって作業効率UPが期待できますので、ぜひ最後まで読んでみてください! f:id:tb_hiromu_fujitani:20220404175534p:plain

xTabが作業効率UPに役立つ3つのポイント

前提として、人間は同時に複数のことを認知・処理することは不可能です。もし可能であれば、車の運転中に読書だってできるはずです。 つまり、タブを大量に開いていることは、認知・処理できないものを常に目の前に置いていることになります。 優先順位をつけることができない複数の要求にさらされると人間の脳は圧倒され、うまく機能しなくなるのです。 そういった前提を元に、作業効率UPに役立つ3つのポイントを紹介します。

①メモリ使用率を大幅に下げられる

ブラウザで使うタブを減らすことでメモリ使用率を大きく下げることが可能です。 Google Chromeは意外にもメモリ使用率が非常に高く、その使用率はタブを開けば開くほど向上します。動きのあるサイトだとCPU使用率まで上がってしまうことも。 高性能なPCであれば、影響は少ないかもしれませんが、ある程度のスペックがないと影響を受けてしまいます。

f:id:tb_hiromu_fujitani:20220404180011p:plain

②集中力が向上する

タブを閉じる癖をつけることで集中力、認知能力が向上し、作業効率のUPにつながります。

タブの開きすぎは目の前の作業に集中ができていない証拠でもあります。 「あ、そういえば」といった感じで、目の前のタスクとは関係のないページを見てしまい、そのページに関連したタスクに意識がスイッチングしてしまいます。 すると、元々やっていたタスクが忘れられ、新しいタスクに意識が飛んでいき、いつまでもタスクが終わらない状況になりかねません。

以下の記事で「デスクが散らかっていると集中力も生産性も低下する」ことが解説されております。

www.dhbr.net

アメリカのプリンストン大学の研究結果で、乱雑な環境は人の認知能力と集中力を低下させることがわかっているとのこと。これはデスクに限らずブラウザのタブも例外ではないと考えます。

③作業ミスを減らせる

タブを開きすぎていると、自分がどのタブで作業をしていたかがわからなくなり、作業ミスの原因になります。 例えばブログ記事の作成で、同じ編集画面を2つ開いて、他のサイトで情報収集をしている間に、どちらの編集画面が最後に編集していたかがわからなくなり、誤ったほうに更新をかけて、これまでの作業がリセット…という事態になったりします。

これがもしAWSの設定値の変更中に調べ物をして、誤ったAWSの設定変更をしてしまった…となると大惨事です。 基本的に目の前の作業と関係のないタブは閉じる!というクセがついていればこういったミスは減らすことが可能です。

ブラウザのタブを開きすぎないことに慣れる

ブラウザは本当に強い意識を持たないとすぐにタブだらけになってしまいます。私も最初はそうでした。 ここでGoogle Chrome拡張機能「xTab」がとても便利です。 事前に設定しておいたGoogle Chromeの最大タブ数を超えてタブを開けなくする拡張機能です。

意識しなくても拡張機能が強制的にタブを閉じてくれますので、「タブを閉じるクセ」を付ける良い練習になります。 練習の結果、開きすぎないことに慣れると、想像以上に作業効率がUPすることに気づくことでしょう。 chrome.google.com

xTabの設定内容

「Tab limit」:開ける最大タブ数を設定します。 「Close least recently used」:一番手前で使用したタブから閉じていきます。 「Close least accessed」:アクセスが少ないタブから閉じていきます。 「Close Oldest」:古い順番にタブを閉じていきます。 「Block new tabs from opening」:新しいタブを開くことをブロックします。 f:id:tb_hiromu_fujitani:20220404181126p:plain

実際に半年間使った感想

私は以下の設定です。10個を超えるタブ数になると以下のように新規タブのオープンがブロックされます。 TabLimit:10 設定:Block new tabs from opening

最初は10って意外に少なくて、慣れるのが大変でしたが、慣れたら10個どころか2~3個程度しか開かなくなりました。 その分、PCが軽くなったり、気が散らなくなって作業も捗ります。人間は最初はつらいことでも慣れたうえにクセができてしまえば、問題ありません! f:id:tb_hiromu_fujitani:20220404181530p:plain

類似プラグイン「OneTab」はどうなのか

簡易的なブックマークのような感じで開いたタブをプラグイン内にまとめる機能が「OneTab」の特徴ですが、個人的にはあまりお勧めしません。

整理が得意であれば問題ないのですが、整理が苦手な人は、逆効果になると思っています。 私の場合、机の下や引き出しの中に物を詰め込んで、実質は整理されていないのに整理した気になった状態になりがちなのですが、それと同じことがブラウザで起きてしまいそう…と思いました。

「xTab」と「OneTab」を併用するのはアリかもしれません。

まとめ

以上、タブを自動的に閉じてくれるChrome拡張「xTab」が作業効率UPにつながる理由と、集中力や作業ミスにつながるなどの悪影響を解説しました。 最初は、新しいタブを開くのをブロックされて、不便に感じるかもしれません。それを乗り越えた先には、大きく作業効率が上がっているはずです! ぜひ試してみてください。

トラストバンクではエンジニアを募集しております! ポジションにとらわれず、いろいろなチャレンジができますのでご興味ありましたら是非募集ページをご覧ください!

www.wantedly.com

S3のObjectCreated:PutイベントでLambdaが起動しなかった話

こんにちは、サーバーサイドエンジニア1年目のharukiです。

先日、AWS上でS3トリガーのLambda起動を試していたところ、なかなか上手く行かずに少しハマってしまったため、 今回はそちらの原因と対処法&プチ調査結果についてまとめたいと思います。

本題の前に

まず、今回のお話に出てくるシステムのイメージ図はざっくりと下記の様な形で、 LaravelからのS3へのファイルアップロードに対してLambdaを起動するといった仕組みになっています。

なお、この際AWSの3Sイベント通知ではObjectCreated:PutのみをLambdaのトリガーイベントとして設定していました。

f:id:h0r4k:20220404164302p:plain

問題発生の状況

今回発生した問題としては、アップロードしたファイルサイズによってLambdaが実行されたりされなかったりするというものでした。 (7.9MBのファイルでは成功し、16.9MBのファイルでは失敗するといった感じでした)

はじめは、Lambdaの処理に時間がかかって強制終了しているだけかなと思っていたのですが、 メトリクスのInvocationsをみてもピクリともしておらず、 そもそもLambda自体が呼び出されていないのではということで、 S3アップロード時に発生するイベントについて確認してみました。

実際に発生しているイベントを確認してみる

まず、前回のファイルアップロード時にLambdaの起動に成功・失敗したそれぞれのファイルについて、 LocalStackを使用して実際に発生するイベントを確認してみました。

前回成功していたファイル

前回Lambdaの起動に成功していた7.9MBのファイルでは、ファイルアップロード時にObjectCreated:Putのイベントが発生していました。

{
    "Records": [
        {
            "eventName": "ObjectCreated:Put",
            "s3": {
                "object": {
                    "size": 7888901,
                }
            }
        }
    ]
}
前回失敗していたファイル

前回Lambdaの起動に失敗していた16.9MBのファイルでは、ファイルアップロード時にObjectCreated:CompleteMultipartUploadのイベントが発生していました。

{
    "Records": [
        {
            "eventName": "ObjectCreated:CompleteMultipartUpload",
            "s3": {
                "object": {
                    "size": 16888901,
                }
            }
        }
    ]
}

上記の結果通り、ファイルサイズの違いによってeventNameObjectCreated:PutObjectCreated:CompleteMultipartUploadで異なっていることが確認できました。

解決方法

ということで、AWSの3Sイベント通知に上記の2つObjectCreated:PutObjectCreated:CompleteMultipartUploadをLambda実行のトリガーとして設定することで、無事に問題が解決することが分かりました。

もう少し詳細に

好奇心でもう少し詳細に調べてみます。

まず、Laravel8のS3ファイルアップロードにはleague/flysystem-aws-s3-v3が使用されており、さらにその中ではaws/aws-sdk-phpが呼び出されています。

そしてこのaws/aws-sdk-phpupload関数まで辿っていくと、Docコメントに「アップロードサイズが閾値(mup_threshold)を超えると、multipart uploadsを使用するよ」と記載されていました。

f:id:h0r4k:20220403045255p:plain
aws-sdk-php(3.216.3)のupload関数のDoc

こちらにも同様の記載があります。
Amazon S3 Transfer Manager with AWS SDK for PHP Version 3 - AWS SDK for PHP

mup_threshold (int)
Size in bytes in which a multipart upload should be used instead of PutObject. Defaults to 16777216 (16 MB).

はたしてホントでしょうか・・・?
確かめてみます。

確かめてみる

先程のDocに記載されていた、mup_thresholdの値を基準に、224-1 (16777215) byteのファイルと224 (16777216) byteの2種類のファイルを作成しました。

では、実際にこれらの2つのファイルをアップロードし、イベントの差異を確認してみましょう。

16777215 byteのファイルアップロード時の3Sイベント

結果こちらはObjectCreated:Putとなりました。

{
    "Records": [
        {
            "eventName": "ObjectCreated:Put",
            "s3": {
                "object": {
                    "size": 16777215,
                }
            }
        }
    ]
}
16777216 byteのファイルアップロード時の3Sイベント

結果こちらはObjectCreated:CompleteMultipartUploadとなりました。

{
    "Records": [
        {
            "eventName": "ObjectCreated:CompleteMultipartUpload",
            "s3": {
                "object": {
                    "size": 16777216,
                }
            }
        }
    ]
}

やはりDocに記載の通り、mup_thresholdの値 224 byteがPutObjectCreateMultipartUploadの実行の境目となっているようです。

ということで、今回はS3ファイルアップロード時のイベントについてのプチ調査記事でした。
最後まで見て頂きありがとうございました。

さいごに

これまで培った技術力を活かして地域を元気にしたいという想いを持っている方を絶賛募集中です。
ご興味をお持ちいただけましたら、是非以下の募集ページをご覧ください!

www.wantedly.com

SREがLoGoチャットボットを作ってみた

パブリテック事業部でSREを担当している大場です。
先日、LoGoチャットボットの理解を深めるため、自分でボットを作成してみたのでノウハウを書き留めておこうと思います。

LoGoチャットボットとは

パブリテック事業部では、自治体さま向けにLoGoチャットというビジネスチャットを提供していますが、あわせてLoGoチャット上で動作するボットもご利用いただいています。
LoGoチャットはdirectのOEM製品であるため、「daab SDK」を使ってボットを開発することができます。
daab SDKの詳細は以下を参照してください。
daab デベロッパー | daab デベロッパー

※実際にLoGoチャットボットを動かすには、LoGoチャットのアカウントが必要です。

「daab SDK」を使ってみる

機能としては、特定のメッセージを投稿するとボットが返事をしてくれるというだけのシンプルなものです。
Node.jsで実装しますが、実際のコードはこちらです。

'use strict';

module.exports = (robot) => {
  robot.hear(/心の俳句|おはようございます|おはよう$/i, (res) => {
    const haiku_list = [
        "草むしり いいことなんて たぶんない",
        "やわらかく おいしいものを 我は所望す",
        "夏の日に ゴキブリ退治 光る汗",
         == 省略 ==
        "春がきて それがすぎたら 次は夏"
    ];
    let idx = Math.floor(Math.random() * Math.floor(haiku_list.length));
    res.send({
        text: haiku_list[idx],
    });
    res.send({
      text: "友蔵 心の俳句",
    });
  });
};

robot.hearでメッセージを受け取り、res.sendでボットからメッセージを送信します。
今回は、”心の俳句”、"おはようございます"、"おはよう"のいずれかのメッセージを送信すると俳句のリストからランダムで選択したメッセージをボットが送信する処理になっています。
これでボットの実装は完了です。

動かしてみる

  • ボットのアカウントを準備する
    まずはボットのアカウントをLoGoチャットに参加させます。

  • daabのインストールとdaab initを実施する

$ npm install -g daab

$ daab init
? package name (作ったフォルダ名) 【そのままEnterでOK】
? version (0.1.0)  【そのままEnterでOK】
? description 【そのままEnterでOK】
? author 【そのままEnterでOK】
? choose files you need ~ 
> ( ) .cfignore
  ( ) .dockerignore
・・・略 
【そのままEnterでOK】

プロジェクトフォルダの中に以下のような構成(ファイル・フォルダ)が作成できていれば成功です。

$ ls -la
bin/
scripts/
external-script.json
package.json
  • ログインする
$ daab login
[2022-03-30 03:47:19]  WebSocket opened.    
Email: 【ボットのEmailアドレスを入力してEnter】
Password: 【ボットのパスワードを入力してEnter】
logged in.

$ cat .env  | grep HUBOT_DIRECT_TOKEN
HUBOT_DIRECT_TOKEN=【ランダムな文字列が追記されている】

正常にログインできると、.envファイルにHUBOT_DIRECT_TOKENが追記されます。

  • ボットを起動する
$ daab run 
npm WARN deprecated chokidar@1.7.0: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
npm WARN deprecated fsevents@1.2.13: fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.
npm WARN deprecated urix@0.1.0: Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated resolve-url@0.2.1: https://github.com/lydell/resolve-url#deprecated

== 省略==

[2022-03-30 03:58:33]]  WebSocket opened.

WebSocket opened.が表示されれば起動完了です。

動きました!

最後に

簡単にボットを作ることができ、友蔵オタクのメンバーにも喜んでいただけましたw
実際はAWS ECSに乗せて動かしたりしているので、今後この辺りも書いていけたらと思います。

トラストバンクではエンジニアを募集しております!
ポジションにとらわれず、いろいろなチャレンジができますのでご興味ありましたら是非募集ページをご覧ください! www.wantedly.com