RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのエンジニアブログ

マイクロサービスアーキテクチャにおけるサービス分割の難しさ

大阪オフィスの移転を機に、生活リズムも絶賛見直し中の @kawanamiyuu です。

今回は昨年度から取り組んでいる、通称「かみせんプロジェクト」の今期の成果(の一部)についてご紹介します。

かみせんプロジェクトとは

かみせんプロジェクトとは「開発の未来に先手を打つプロジェクト」の略称で、2017 年度に取り組みが始まりました。

ミッション

『継続的に新しいことに取り組み、組織要望に対して迅速にトレンド技術で応えることができるようになる』

目標

具体的には以下の実現のための技術検証や知見獲得を、社内システムのマイクロサービス化を題材に行っています。

  1. ソフトウェア規模に比例した開発効率低下の軽減
  2. 無停止デプロイ、不具合発生率低下などの高可用性の実現
  3. 現行ソフトウェアからの段階的な移行の実現

社内システムのマイクロサービス化

社内システムの概要

  • LAMP (PHP) で構築されたモノリシックな Web アプリケーション
  • エンジニア、経理担当者などが、社内からのみアクセスして利用する
  • プロジェクト管理機能、開発稼働集計機能などを提供する

かみせんプロジェクト開始前

  • すべての機能がモノリシックなアプリケーションとして提供されている

f:id:kawanamiyuu:20180925154624p:plain

2018 年 9 月現在

  • モノリシックなアプリケーションから、一部の機能をマイクロサービスとして切り出した
  • マイクロサービスは AWS 上でコンテナとして動作している

f:id:kawanamiyuu:20180925144057p:plain

マイクロサービスの結果整合性

マイクロサービス化を進めるとバックエンドで複数のサービスが協調して動作することになり、これまではデータベースのトランザクション機能により担保されていたデータの一貫性について別のアプローチが必要になります。

かみせんプロジェクトの今期の取り組みの 1 つとして、マイクロサービスの結果整合性について調査や技術検証を行いました。

課題感

  • 複数に分割されたサービス間のデータの一貫性をどのように保てばよいか
  • データ不整合が生じた場合、どのようにリカバリーすればよいか

検証内容

  • ある機能を 2 つのサービス (図中の project-servicefunction-service) として切り出す
    • モノリシックなアプリケーションを、複数(社内での利用実績がない、あるいは少ない)の言語やフレームワークを利用して分割することも技術検証の一環
  • あるリソースを新規登録する際に、従来 1 トランザクションで行っていた処理 (SQL) の一部を、今回切り出したサービスの API 呼び出しに置き換える
  • データの整合性はリトライ処理で担保する

検証結果(得られた知見)

サービスの分割は難しい
  • 大前提としてサービスをまたぐトランザクションが発生しないようにサービスを分割すべき
  • 今回のように同一トランザクションでデータ更新をしたい処理であれば、サービス同士が疎結合ではないということであり、そもそもサービス分割の粒度が正しくない可能性が高い
  • ドメインの知識が乏しい状態では適切なドメイン境界を認識することはきわめて難しい
  • ドメインの知識が増えた中盤になってから分割し直すことも、別の意味で難易度が高そう
    • 自動テストなど品質担保の仕組みや、作り直しに対する組織の理解の度合いで実現可能性が大きく変わる
結果整合性の担保は難しい
  • 今回のようにリトライ(有限回数)で整合性を担保する場合、すべて失敗する可能性もゼロではなく、最終的にログなどから手動リカバリーできる仕組みを考えておく必要がある
  • 今回は時間の都合で検証していないが、メッセージキューを利用したイベントソーシングなアーキテクチャも検討したい
  • 分散トランザクション(二相コミットなど)の手法を使う選択肢もあるが、システムの複雑さや難易度が一気に増加しそうで現実的ではなさそう

最後に

  • マイクロサービスの分割や結果整合性に関する知見は、情報としては世の中にありますが、実際に自分の手を動かして検証することで、改めてその課題感を実感するとともに、現実のサービス開発にマイクロサービスアーキテクチャを適用する難しさも明らかになりました
  • ラクスでは現在、HR(人事労務)領域を対象した新サービスの開発に取り組んでおり、この「かみせんプロジェクト」で得られた知見が現実のプロジェクトで活かされようとしています。例えば

ラクスでは現状に満足せず開発の未来に先手を打っていける仲間、HRTech に興味があるエンジニアを募集しています!

www.wantedly.com

iPhoneだけでAPI実行!!「ショートカット」アプリを試してみた

はじめに

新卒2年目エンジニアのkasuke18です。
つい先日iOS12がリリースされました。リリースされた内容は数多くありますが、その中でも気になったのが「ショートカット」というアプリです。このアプリをうまく使えばiPhone単体でAPIの実行が可能になります。実際に試してみましたので、紹介します。

もくじ

「ショートカット」アプリについて

「ショートカット」アプリの画像
リリースノートShortcuts 2.0 release notesを見ると、「ショートカット」アプリはiOS12の以前に「Workflow」アプリとして公開されていたようです。
「ショートカット」アプリでは、ビジュアルプログラミング言語のようにアクションと呼ばれる構成要素を組み合わせて1つのショートカットを作成します。アクションにはiPhone端末の設定変更他アプリの操作・データの受け渡しといったものが用意されているほか、変数・条件分岐・繰り返し(for, foreach)といった制御を行うものも用意されています。

作成したショートカット

内容

クリップボードに保存されている画像のリンクに対してOCRAPIを実行し、画像内の文字をテキストに変換して出力する、ということをやってみました。今回使用したOCRAPIFree OCR API | OCR.spaceです。POSTパラメータやレスポンスのJSON構成はリンク先でご確認ください。

作成例

まずはPOSTリクエストを送信する部分です。

POSTリクエストを送信するショートカット
図1. POSTリクエストの送信

今回POSTパラメータとして必要な情報はAPIキー画像内の文字の言語base64エンコードされた画像の3つです。このうち画像内の文字の言語は日本語で固定としているので、残り2つを取得する処理はサブルーチンとして別ショートカットに切り出し、それらを呼び出す方式をとっています。ではそれぞれのショートカットを見ていきます。

 

APIキーの取得処理です。APIキーは環境変数に持っておきたいのですが、さすがにそこまではできないようなので、今回はリマインダーアプリに保持・読み出すようにしています。

APIキーを「リマインダー」アプリから読み出すショートカット
図2. APIキーの取得
内容はAPIキーを保持しているリマインダーを検索し、その中から今回使用するOCR.spaceというタイトルの項目からAPIキーを取得しています。
ショートカットの最後では、メインのショートカットに値を渡すため、変数から値を取り出して終了しています。

 

次にbase64エンコードされた画像の取得処理です。このパラメータに設定する値はdata:image/[フォーマット],[base64エンコードされた画像]ですので、実際は拡張子画像をbase64エンコードしたテキストの2つが必要になります。
まずは拡張子の取得処理です。

URLから画像を取得し、その拡張子を取得するショートカット
図3. 拡張子の取得

大きな流れとしては、まずクリップボードの内容がURL形式どうか確認し、URL形式ならその内容を取得します。さらにその内容がイメージであれば拡張子を、そうでなければnoneというテキストを返却する、という処理を行っています。このnoneというテキストは、ショートカットを実行する側の処理でnoneを受け取り、エラーとして処理を終了するために利用します。
次が画像をbase64エンコードしたテキストの取得処理です。
URLから画像を取得し、そのbase64エンコードしたテキストを取得するショートカット
図3. 画像をbase64エンコードしたテキストの取得

これは拡張子の時とほぼ同じ処理の流れをしていて、拡張子を取得していたところを画像をbase64エンコードしたテキストを取得するように変更しただけです。

 

最後にメインのショートカットで他のショートカットを実行する&その結果を受け取る処理と、レスポンスJSONをパースする処理を行います。 まずは他のショートカットを実行&その結果受け取る処理です。

別ショートカットを実行し、その結果を受け取るショートカット
図4. 別ショートカットの実行

処理の流れは画像の通りです。ショートカットを実行し、その結果が拡張子ではないときは中断されたことを通知しショートカットを終了します。
続いてレスポンスJSONをパースする処理です。
レスポンスJSONをパースするショートカット
図5. レスポンスJSONのパース

「ショートカット」アプリ内ではJSON辞書という単語で扱われています。アクションとしては辞書の値を取得というもので、これは組み合わせればネストされたJSONのパースも可能です。また今回は結果出力のため、最後にメモに書きだすようにしています。

実行結果

以上のサンプルを、前回私が書いた記事の画像に対して実行した結果が以下となります。

OCRで認識する画像
図6. OCRで認識する画像

ショートカット全体を実行した結果
図7. 実行結果

おわりに

今まではちょっとAPIを試してみたいだけでもPCを用意する必要がありましたが、この「ショートカット」アプリを使用すればiPhone単体で簡単にできます。また今回は紹介していませんが、テキストに対して正規表現を用いたマッチングもできるので、スクレイピングも可能です。iPhoneユーザの方は試してみてはいかがでしょうか。
最後までご覧いただきありがとうございます。

参考文献

付録:今回使用したアクション

アクション名とその使い方を以下にまとめました。

  • API実行
    • URL
      • URLを次のアクションに渡す
    • URLの内容を取得
      • 受け取ったURLをリスエストし、レスポンスを次のアクションに渡す
  • クリップボードをリクエスト用に加工
    • クリップボードを取得
    • 種類を取得
      • 受け取った値のデータ種類(イメージ・URLなど)のテキストを次のアクションに渡す
    • Base64エンコード
      • 受け取った値をBase64形式でエンコード・デコードした値を次のアクションに渡す
    • ファイルの詳細を取得
      • 受け取った値(ファイル)の詳細(拡張子・サイズなど)を次のアクションに渡す
  • JSONのパース
    • 辞書の値を取得
      • 受け取ったJSONから指定したキーの値を次のアクションに渡す
  • 制御
    • 変数を設定
      • 受け取った値を変数に代入する
      • 受け取った値をそのまま次のアクションに渡す
    • 変数に追加
      • 受け取った値を変数に追加する(Listにappendするようなイメージ)
      • 受け取った値をそのまま次のアクションに渡す
    • 変数を取得
      • 変数から値を取り出し、次のアクションに渡す
    • 次の場合(if~else文)
      • 受け取った値と指定した値を比較する(次と等しい・次を含む・より大きい・より小さい)
    • それぞれで繰り返す(foreach文)
      • 受け取ったリスト形式の値に対して1つずつ処理を行う
    • ショートカットを実行
      • 受け取った値を特定のショートカットに渡し、その実行結果を次のアクションに渡す(メソッドのようなイメージ)
  • APIキーを取得する
    • リマインダーを検索
      • 条件に合致するリマインダーを検索し、その結果を次のアクションに渡す
    • リマインダーの詳細を取得
      • 受け取った値(リマインダー)の詳細(メモ・タイトルなど)を次のアクションに渡す
  • その他
    • テキスト
      • 指定したテキストを次のアクションに渡す
    • 通知を表示
      • タイトル・メッセージを指定し、その内容を通知として表示する
    • メモを作成
      • 受け取った値をメモに新規登録する
    • "ショートカット"を終了
      • 現在のショートカットを終了する
      • 現在のショートカットに含まれる後続のアクションは実行しない

京都アジャイル勉強会に参加しました

はじめに

こんにちは。ラクスエンジニアのstrongWhiteです。今回は8月に京都アジャイル勉強会に行ってきましたのでレポートしようと思います。アジャイルとは、要求仕様の決定や変更に対して、柔軟に対応するためのソフトウェア開発手法のことです。昨今有名になりつつあるアジャイルですが私としても興味がありましたので今回勉強会に参加してみました。
※この記事ではアジャイルに関する詳細な説明は省きます。アジャイルスクラムを初めて聞く方は馴染みのない用語が出てきますがご了承ください。

京都アジャイル勉強会とは

アジャイルスクラムを実践しようとしている(もしくは実践中の)人を対象とした勉強会で、自身(あるいは自社)が抱えているアジャイルスクラムに関する疑問、不安などをざっくばらんに議論し、お互いに理解を深め合う会です。ちなみに私が行ってきたのは以下の勉強会です。

connpass.com

私の所属するチームではアジャイルスクラムを取り入れた開発をしているので、今回はアジャイルスクラムを実践する中で私が抱えている疑問や不安を勉強会に参加されている皆さんにぶつけてみることにしました。

学んだこと

ディスカッション形式の勉強会は初めてだったので新鮮でした。また、アジャイルスクラムに対する理解も少しながら進んだ気がしました。私としては日々スクラムアジャイルを実践する中でプロダクトバックログからスプリントバックログを出すまでに時間がかかり次のスプリントが始められないという課題を抱えていたのですが、今回の勉強会でとある方から「見切り発進的に次のスプリントを始めるのはよくないので、時間がかかってもいいから全てのスプリントバックログを出してから次のスプリントをスタートすべき」という助言をいただき、少し勇気をもらえました。

終わりに

今回のようなディスカッション形式の勉強会は講義形式のお堅い感じは全くないので私としてもリラックスして受講できました。機会があればまたアジャイルスクラム系の勉強会に参加したいと思います。チームとしても私としてもまだまだアジャイルスクラムを始めたばかりなので、また疑問が出てきたらこういう勉強会の場で解消していこうと思います。

参考

【超入門】RDBとNoSQLの違いに着目!NoSQLに求めるものとは?

こんにちは、MasaKuです。

ビッグデータという言葉をよく目にしますが、その背後にある技術についてはあまり理解していませんでした。
そこで、ビッグデータを支える技術のひとつであるNoSQLについて興味が生まれたので、今回の記事では、NoSQLについて勉強した結果についてまとめようと思います。

(本記事の執筆には以下の書籍を参考にさせていただきました)
NOSQLの基礎知識 ビッグデータを活かすデータベース技術

はじめに

現在、Twitterは、1日あたり10テラバイトを超えるデータを扱っているそうです。
10テラバイトというと、書籍一冊のデータ量(50万文字)とすると書籍1000万冊分に相当します。

モバイルデバイスからも簡単にアクセスして写真や動画コンテンツを発信できるWebサービスが普及してきたことがビッグデータの発生の起因のひとつになったと言えるでしょう。

ビッグデータの対応には3Vという以下のような特徴があります。

  • Volume(膨大な量)
  • Velocity(速さ)
  • Variery(多種多様)

今後、更にリッチな情報を扱うWebサービスが普及してくると、ビッグデータを処理する技術がますます重要になることから、NoSQLの技術発展が期待されます。

NoSQLとは

PostgreSQLMySQLなどのRDBでは対処しづらいようなビッグデータに対応すべく生み出された技術で、SQLを使用しないということが特徴です。
「Not Only SQL」の略であり、「SQLだけでなく、新しいデータベースの技術も利用する必要があるというムーブメントのことである」と多くの方に認識されています。
しかし、「NoSQLとはズバリこういうこと!」という定義についてはまだ明確化していないようです。

NoSQLとして代表的なものには、GoogleBigTable、アマゾンのAmazon DynamoDBなどがあります。

RDBとの違い

NoSQLとRDBとの違いについて以下にまとめました。

  • 機能は豊富ではない
  • データの整合性が緩い
  • 結果整合性でよいという考え

NoSQLでは、RDBで当たり前に利用できるJOIN(結合)が通常はサポートされていません。
また、同時実行制御(排他制御)を成立させるトランザクションの機能が緩められており、データの整合性よりも、大量のデータを素早く処理することを優先しているという特徴があります。

NoSQLとRDBの特性の違いを説明する上で重要な「CAP定理」という定理があります。
分散型データベースシステムにおける三大要件として以下が存在します。

  • Consistency(整合性)…常に同一のデータを参照する
  • Availability(可用性)… 常に読み出しと書き込みができる
  • Partition Tolerance(分断耐性)…ネットワークが分断されても間違った結果を引き起こさない

分散型データベースシステムでは、上記の3つのうち最大2つしか満たすことができない、というのがCAP定理です。

f:id:MasaKu:20180918134539p:plain
CAP定理

RDBにはACIDという特性が存在し、トランザクションが信頼性をもって実行されるための必要条件を定義されています。
一方、BASEというものも存在し「アプリケーションは常時稼働し、常に整合性を保つ必要はないが結果的に整合性がとれる状態に至るという特性を備えているべき」という考え方があります。

CAP定理の提唱者であるEricBrewer氏は以下のように説明してます。

システムに整合性(C)と分断耐性(P)が求められる場合には、AICD特性を完備しなければならない。
だが、整合性(C)よりも可用性(A)と分断耐性(P)が求められるのであれば、そのシステムはBASEの特性を持つべきである。

RDBはCA(整合性と可用性)に分類され、ほとんどのNoSQLデータベースがCP(整合性と分断耐性)かAP(可用性と分断耐性)に分類されます。

RDBとNoSQLでは期待している性能が異なることから、NoSQLがRDBを完全に代替するものではないことがわかります。

NoSQLに期待すること

NoSQL全般には以下のような要件を満たすことが期待されています。

  • 一台のサーバには収容できないほど膨大なデータを扱う
  • データを複数のサーバに分割して割り当てる
  • 高価なハードウェア等ではなく、安価な汎用ハードウェアの上で稼働する
  • データに紛失がなく、データは安全な状態に格納されている
  • システム全体としては、いつでも使える状態にある
  • 障害が発生しても短時間で復旧できる
  • リアルタイムに近い応答性能を備えている

また、データを高速に処理する上で、高度なデータベースチューニングの技術を必要としないことも特徴です。

データのサイズや形式が頻繁に変化するようなアプリケーションをRDBでデータを高速で処理し続けるためには、データベース設計に対する高い技術力を持ったエンジニアが常時対応しなければなりません。

これまでのRDBでは十分な性能が得られなかったり、RDBで実現しようとすると、構造が複雑になり、コストがかかりすぎるという問題を回避するための手段としてNoSQLが選択肢の一つとなりうることが期待されます。

NoSQLのデータモデル

NoSQLには様々なデータモデルが存在します。

キーバリュー型

f:id:MasaKu:20180918000114p:plain
キーバリュー型

RDBのようなテーブルや関係性を定義せず、キーとバリューという組み合わせからなるシンプルなデータモデルです。
データが増えるにつれて表が縦の方向に伸びていくイメージです。
データモデルが単純であることからデータを容易に分割可能なことから、スケールアウトに最適なのが特徴です。

カラム指向型

f:id:MasaKu:20180918000149p:plain
カラム指向型

上記のキーバリュー型にカラムの概念を持たせたデータモデルです。
行に付与されたキーが複数のカラムを持つことができます。
カラム数はRDBのように固定ではなく、動的に追加していくことができます。
RDBを利用していると異質に思えるかもしれませんが、ほかの行には存在しないカラムを持つ行を作ることができます。

ドキュメント指向型

f:id:MasaKu:20180918000223p:plain
ドキュメント指向型

JSONXML形式で記述されたドキュメントの形でデータを管理することができます
各ドキュメントは階層構造を持たず、相互の関係を横並びに管理します。
RDBのように固定されたデータ設計が不要なことから「スキーマレスである」と言われます。

私はドキュメント指向型の説明を読んだ際、上記のカラム指向型との違いを明確に認識することができていませんでしたが、以下のようなものなのだと理解しました。

f:id:MasaKu:20180918002843p:plain
ドキュメント指向型の例

ブログの投稿履歴とメールの送信履歴をドキュメント指向型データベースに記録したとします。
これらは全く異なる性質のデータですが「投稿日と送信日が2018/9/18のデータ」と指定することで、関係するデータが取得できます。
このようなデータの性質が異なるものや、これまで取得していたデータの形式が唐突に変わってしまうような対象でも、ドキュメントの形式でデータベースに格納し、データを処理できるようにするのがオブジェクト指向型のデータベースの特徴なのだと思いました。

グラフ型

f:id:MasaKu:20180918000254p:plain
グラフ型

データとデータ感のつながりを管理できるデータモデルです。
グラフ型のデータベースには以下の構成で表現されます。

  • ノード
  • リレーションシップ
  • プロパティ

例えば、FaceBookの友達関係をグラフ型で表現すると以下のようになります。

  • Aさんというアカウントが存在します(ノード)
  • AさんはBさんと関係があります(リレーションシップ)
  • AさんとBさんは友達同士です(プロパティ)

この基本構造を拡張していくと「Aさんの友達であるBさんの友達」や「Aさんと友達になってから3年以上経過したアカウント」といった検索も可能になります。

おわりに

いかがでしたでしょうか。
筆者も、MongoDBというドキュメント指向型NoSQLを利用して簡単なWebアプリケーションを作ってみましたが、NoSQLについて調べて見ると様々なデータモデルが存在することがわかりました。
それぞれのデータモデルごとの強みが光るようなWebアプリケーションの特性についても今後調べていきたいと思いました。

参考文献

NOSQLの基礎知識ビッグデータを活かすデータベース技術

NoSQL - Wikipedia

ブリュワーのCAP定理~データストレージの選定基準 - 浜村拓夫の世界

「終わらないスクラム」を終えて得たスクラムの実践に関する5つの学び

id:radiocat です。9/13に東京オフィスで開催したMeetupに登壇し「終わらないスクラム」というタイトルで発表しました。今回のイベントを通じて、私たちが継続してスクラムに取り組んでいくうえでの様々な気づきを得ることができたので、それらを5つの学びとして記事にまとめてみました。ご参加頂いたみなさま、ありがとうございました。

rakus.connpass.com

発表の概要

発表の前半は私たちのチームが取り入れたアジャイル開発のプラクティスの説明で、今年3月の社内イベントで発表した内容がベースとなっています。それらの概要は以前のブログ記事にまとめていますのでご参照ください。

tech-blog.rakus.co.jp

発表の中盤からは開発を少しずつアジャイルにし、やがてスクラムにチャレンジしていくために私たちが参考にした書籍やネット上の情報を紹介しました。そして後半部分では、現在のプロジェクトでも引き続きスクラムで開発を進めている中で新たに取り組んでいることを紹介しました。

speakerdeck.com

5つの学び

発表後の懇親会では参加者の方々からたくさんフィードバックを頂いて、それぞれの現場で実践しているスクラムの取り組みなども教えていただき、とても有意義なイベントにすることができました。頂いたフィードバックも交えて、5つの学びをご紹介します。

1. 役割に徹することができる体制でスクラムを始める

私たちのスクラムチームではプロダクトオーナー(以下PO)をデザイン部門のメンバーが担っています。

f:id:radiocat:20180917161611p:plain:w500

その理由は大きく2つです。

  • 開発チームは大阪、POのデザイン部門とステークホルダーの事業部門は東京が拠点
  • BtoBのサービスであるため、デザイン部門はデザインの作り込みよりもUI/UXをしっかり検討することが求められる

この話をした時に、「(上記の体制を書いた)スライドを見た時にそうだと思った」というフィードバックを頂きました。

スクラムチームの中で誰がPOやスクラムマスター(以下SM)を担当するかはスクラムに取り組むうえでの最初の難題の1つです。チームの中で誰がその役割を担えばその役割に徹することができるのかをしっかり問いかけて決める必要があります。

f:id:radiocat:20180917161702p:plain:w500

役割に徹することができない体制でスクラムを始めていたら恐らく失敗していました。世の中的に複数拠点やリモートワークを絡めたメンバー構成は当たり前となっていますし、それぞれの現場に合わせて最適な体制を考える必要があります。

ちなみに、今回の体制の場合は開発部門におけるリーダーという立場の私がSMを担うことがもう1つの課題になりました。

f:id:radiocat:20180917180334p:plain:w500

開発チームが機能するために組織としての役職が邪魔になることもあれば、うまく活用してチームを支援できることもあり、それらをうまく使い分けることも役割に徹するために必要なことです。

2. スプリントの期間は1週間がおすすめ

今回の発表で取り上げた開発プロジェクトでは2週間のスプリントでスクラムを始めましたが、現在はスプリントの期間を1週間にしています。

f:id:radiocat:20180917161734p:plain:w500

同様に1週間でスプリントを回している人から「1週間じゃないとスプリントを回すのは無理」というフィードバックをもらいました。大きな理由は以下の2点です。

  • スプリントの最初に2週間分のタスクを洗い出してプランニングするのが大変
  • 2週間先の見込みを見極めるのが大変

私たちも慣れた今となっては1週間が最もやりやすく感じています。

チームの事情にもよりますが、スプリントの期間をどのくらいの長さにするかもまたスクラムに取り組む上での課題の1つです。私たちが最初にスプリントの期間を決めた当時は他のプロジェクトに稼働を使うメンバーもいたため2週間ぐらいがちょうど良いと判断しました。また、当時は1つのタスクの粒度を小さくする事に慣れておらず、1週間スプリントで大きな粒度のタスクの実行に想定外の時間がかかってしまうとあっという間にスプリントの終わりを迎えてしまう恐れも感じていました。しかし、今となっては1週間スプリントならうまくいかなくても改善して次に活かせば良いという感覚のほうが大きいです。

3. リファインメントと技術的スパイクの大切さと難しさ

次のスプリントに向けてバックログを準備するリファインメントや技術的スパイクの活動はスクラムイベントとしては定義されていませんが、非常に重要でかつチームでルールを決めるのが難しい活動です。私達のチームではリファインメント会議をイベント化して強制的に時間を取るようにしています。

f:id:radiocat:20180917162021p:plain:w500

これについても同様にルールを決めて時間を取っているチームもあるというフィードバックを頂きました。やりかたはチームによっていろいろあるようでしたが、いずれにしてもプランニングまでにバックログをきちんと準備できていなければ、スプリントはうまく回らないというのが共通の理解です。

ちなみに、現在私たちのチームでは1スプリントに2種類のリファインメント会議を実施しています。

  • 開発チーム内リファインメント会議:技術的スパイクの状況確認や認識合わせが中心
  • スクラムチーム全体リファインメント会議:バックログの整理と内容の認識合わせが中心

その理由は主に以下の3点です。

  • 現在取り組んでいるプロジェクトの特性として技術面での不確定要素が多い
  • 開発チームの人数が増えてきたため全体共有や認識合わせの場があったほうが進めやすい
  • POと開発チームの拠点が別れているため時間を決めて実施したほうが進めやすい

いずれも私たちのチームの事情によるものですが、これらを踏まえてリファインメントや技術的スパイクはそれぞれのチームでやりかたを考えて取り組む必要がある活動だと感じています。

4. チームの人数が増えるにつれてスクラムは難しくなる

私達のチームはメンバーが10人を超えたためスケールアウトを検討し始めています。

f:id:radiocat:20180917161815p:plain:w500

これに関連してチームのメンバーが9人いるという人からもフィードバックをもらいましたが、デイリースクラムを時間どおりに終わらせるだけでも難しく、人数が増えるとスクラムは難しくなると感じています。私たちのチームでも、スライドに書いてあるとおりスクラム・オブ・スクラム、LeSS、Nexusといった大規模スクラムの事例を調査して検討をしていますが、事例自体があまり多くないのでまだ具体的な判断は下せていません。

ただ、スライドの下に書いてある「若手メンバーのミニスクラム」を試す期間で、一時的にメインのプロジェクトのメンバーを5人にしたところベロシティが上がってスプリントを以前よりうまく回せるようになったので、やはり5人ぐらいがちょうど良いという感覚も得ています。

5. チームの育成と成長は熱意を持って根気強く

上記の「若手メンバーのミニスクラム」や、以前このブログでも紹介した「スクラムクイズ」に関しては良いフィードバックを頂きました。

f:id:radiocat:20180917161931p:plain:w500

チームのメンバーひとり一人がきちんとスクラムに向き合わなければスクラムをうまく回すことが難しくなります。フィードバックの中でその点に課題を持っているチームの話もいくつか聞くことができましたが、チームの中で熱意をもって進められるメンバーがいないとスクラムを続けていくのは難しいと感じました。

我々もまだまだ試行錯誤しながら様々な取り組みを行っているところですが、そのためにも他のチームの事例や課題はとても参考になります。そういう意味で、今回のイベントではたくさんのフィードバックを頂き、私たち自身の新たな学びを得ることができました。

この学びをまたチームに持ち帰ってさらにスクラムを前進させていきたいです。スクラムの習得はまだまだ終わりそうにありません。

f:id:radiocat:20180918005626p:plain:w500


今回のイベントをきっかけに当ブログに「終わらないスクラム」というカテゴリを作りました。今後もスクラムの取り組みで得たことを随時発信していきたいと考えていますので、引き続きチェックして頂けますと幸いです。

f:id:radiocat:20180917161530p:plain:w500

IoT初心者向け!「MQTT」について簡単にまとめてみる

こんにちは。開発エンジニアのd_shr(id:d_shr)です。
これまではNode.jsやPostgreSQLについて書いていましたが
今回はIoTを支える通信プロトコルMQTTについてまとめます。

tech-blog.rakus.co.jp

tech-blog.rakus.co.jp

はじめに

MQTTは、Publish/Subscribe モデルのメッセージングにより、非同期に1対多の通信ができるプロトコルです。
シンプルかつ軽量に設計されているため、機械同士が通信を行いやり取りするM2M (Machine-to-Machine) や
家電や自動車など多種多様な「モノ」が通信を行いやり取りするIoT (Internet of Things) を実現するのに適した
プロトコルと言われています。

軽量で省電力

HTTPと比較すると、軽量で省電力なプロトコルです。
MQTTのヘッダサイズは2バイト〜とHTTPに比べるとかなり軽量になっており
その軽量さからバッテリーが限られているモバイル通信に適しています。

メッセージングとTopic

メッセージング

MQTTはPub/Subモデルでメッセージングを行います。
Pub/Subモデルではメッセージの送信者をPublisher、メッセージの受信者をSubscriber、メッセージの仲介をするのがBrokerです。
Publisher はメッセージをBrokerへ送るとき、送ったメッセージがどの Subscriber に届くのかなど気にする必要はありません。 Subscriberはメッセージがどの Publisher から送られて来たのか知ることなく欲しいメッセージをBrokerから受け取ります。

f:id:d_shr:20180911095141p:plain

Topic

MQTTでは、Topicと呼ばれるキーを用いてメッセージングを行います。
トピックは「/」で区切られた階層構造になっています。
例:japan/osaka
PublisherはTopicを指定してメッセージを送信し、Subscriberは受信したいトピックをfilterとして指定することで、欲しいメッセージだけを手に入れることができます。

f:id:d_shr:20180911095151p:plain

MQTTの機能

QoS

MQTTではメッセージごとに到達保証に関するQoS(サービスの品質)を指定します。

  • QoS0
    メッセージは最高 1 回 配信される
    メッセージが送信先に届くかは保証されない

  • QoS1
    メッセージは最低 1 回 配信される
    メッセージが送信先に届くことが保証されるが重複して届く可能性がある.

  • QoS2
    メッセージは正確に 1 回 配信される
    メッセージが過不足なく 1 回のみ到着することが保証される.

Retain

Topicごとに最後にPublishされたメッセージをMQTTサーバが保持しておく機能。
MQTTはPub/Subモデルなので、PublishしたときにSubscribeしていたクライアントにしかメッセージは送信されません。
具体的には、10分ごとに更新される情報を得るために新しくSubscribeしても,最長10分間はなにも情報が得られないことになります。
しかし、Retain機能を使うとその時点での最新の情報が得ることができます。

Will

Publisherが切断されてサーバとの通信ができなくなったときに
指定されたTopicとメッセージをSubscriberに送信する機能。
予期せぬ切断などが発生したときに、SubscriberはPublisherが切断されていることを判断できます。

まとめ

IoTを支えるプロトコルMQTTについて簡単にまとめてみました。
世の中にIoTが広がってきているので、それに関連した技術は追っていきたいと思います。

9/13(木) Rakus Meetup Tokyo #1 を開催します(まだ参加枠あります)!

f:id:tech-rakus:20180814160204p:plain

ラクスは「IT技術で中小企業を強くします!」をミッションに掲げ、 メール共有・管理システムのメールディーラーから始まり、経費精算システムの楽楽精算に至るまで、 延べ40,000社を超えるお客様に自社開発したクラウドサービスを提供してきました。

今回(9/13(木))は、ラクスで主力クラウドサービスの開発を牽引するエンジニアによるトークセッションと交流会を開催します。 クラウドサービス開発のエンジニアとして活躍している方はもちろん、 クラウドサービス開発にご興味をお持ちのエンジニアの方も気軽にご参加頂ければと思います。

自社開発ならではの技術・運用ノウハウや、新しい取り組みの成果や失敗談など ご参考にして頂ける情報を積極発信していきたいと考えております。 このイベントが新しい気づきや成長につながる機会を提供する場になるとともに、 ラクス社員と参加者の皆さま、また参加者の皆さま同士で新たなつながりが生まれるきっかけになれば幸いです!

開催概要

【日時】2018/9/13(木) 19:30~21:30(開場は19:00)
【会場】ラクス 東京本社
(〒151-0051 東京都渋谷区千駄ヶ谷5-27-11 アグリスクエア新宿2F [アクセス]
【定員】30名
【申込み】connpass
【参加費】無料
【主催】ラクス

今回のトークテーマ

終わらないスクラム ~楽楽精算のサービス拡大を支えるスクラム開発の取り組み

大塚正道(おおつかまさみち)

ラクスでは、まだ多くの開発チームがウォーターフォール型の開発プロセスを採用していますが、 一部のチームでスクラムによるアジャイル開発に取り組んでいます。 今回は楽楽精算チームでの取り組みを紹介します。 実際にやってみると様々な問題が発生しました。問題解決に向けたアクションや取り組みを通じて得た知見、今後の課題等を事例を交えてお話しします。

テックリード(自称)としてのやっていき! ~iOSアプリ開発チームを率いて

川並裕(かわなみゆう)

若手エースエンジニアが初めてのiOSアプリ開発でテックリードとして奮闘したお話しです。 iOSアプリ開発は、自身も初、メンバーも初、しかも短納期(3ヵ月...)。 このデスマーチを予感させる不利な条件下で、テックリードとしてどのようにチームをリーディングしたのか。 様々な事例を交えてご紹介します。

流行の開発手法ChatOpsとは ~楽楽明細チーム/ChatOpsでルーティン作業をまるごと自動化~

三田英一(みたえいいち)

Jenkinsの導入で自動化が進んだけど、「Jenkinsを毎回開くのは面倒」、「アカウントの作成も面倒」、「非エンジニアに使ってもらうにはちょっとハードルが高い」。 そこで導入したのがChatOps! Slack互換のチャットツール「Mattermost」でルーティン作業を丸ごと自動化しました。 利用したbotツール、システム構成、Hubotスクリプトの実例など、ノウハウを余すことなくご紹介します。

タイムテーブル

  • 19:00 開場・受付開始
  • 19:30 イベントスタート
  • 21:30 終了予定

トークが終わり次第、交流会に移ります。
交流会では、フィンガーフード、ドリンクをご用意致します。
お気軽にご参加ください。

エントリー方法

  • [connpass]よりエントリーをお願いします。
  • ※当日はお名刺2枚ご持参ください
  • ※提供可能な設備:Wi-Fi、電源

会場

ラクス 東京オフィス2F セミナールーム
東京都渋谷区千駄ヶ谷5-27-11 アグリスクエア新宿2F [アクセス]

Copyright © RAKUS Co., Ltd. All rights reserved.