SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Akkaで学ぶアクターモデル入門

アクターモデルによる、APIやデータベースに振り回されないアプリケーション設計と実装

Akkaで学ぶアクターモデル入門 第4回

  • X ポスト
  • このエントリーをはてなブックマークに追加

 マーベリック株式会社のリチャード 伊真岡です。この連載では非同期処理に役立つアクターモデルを学ぶため、JavaとScalaから使えるOSSであり、アクターモデルの実装を提供するAkkaを紹介します。前回の記事ではAkkaのアクターモデルを用いたアプリケーション構成を紹介しました。今回の記事はアクターモデルを用いた設計と実装を、チケットのオンライン販売アプリケーションを題材として説明します。

  • X ポスト
  • このエントリーをはてなブックマークに追加

アプリケーション要件の紹介

 今回は各種のイベント、コンサート、演劇、スポーツイベントなどのチケットをオンラインで購入できるアプリケーションを考えます。

 通常よく用いられるチケット販売方式には先着と抽選がありますが、1つの記事の中で両方の設計を扱うのは記述量が多くなりすぎるので、チケットの先着販売のみを扱うことにします。チケットの先着販売はチケット在庫などの状態管理を含み、さらに同時に複数の購入者からのリクエストを排他制御しつつ処理する必要があるため、アクターのメリットを生かせる題材です。

 多種多様なイベントを扱うチケット販売アプリケーションの場合、ユーザーの行動は大まかに、イベントを探す、イベントの詳細を確認する、チケットを選択する、内容確認の後チケットを購入するという流れになります。

 アクターモデルにとって状態管理は重要なので、この中で状態管理が関係する部分を探してみましょう。まずチケット選択画面で販売期間前、販売期間終了、あるいは売り切れといった状態を表示する必要がありますし、チケット在庫数も管理すべき状態です。さらに購入回数制限があるチケットは、過去の購入履歴を状態として管理し、それをもとに次に来る購入リクエストに対して販売を許可・拒否します。

アクターモデルによる設計

 要件がわかったところで設計に移ります。アプリケーション設計に慣れている開発者なら、ここでUI、Web API層、アプリケーション層、データベース層という構成を考えて設計を始めたくなるかもしれません。しかしアクターモデルによる設計ではそれらを忘れ、アクターのみに集中して、アクター同士がメッセージを送り合う形でアプリケーションを設計します。この辺りの理由やメリットに関しては前回記事をご参照ください。慣れない設計方法かもしれませんが、ぜひこの新しい設計手法を身につけていただければと思います。Web APIとの接続はこの記事の後半で、データベースとの接続は次回の記事で解説します。

 ではアクターモデルによるアプリケーション設計とは具体的にどう進めるのか? というと、以下の3種類の図を用いて設計を行うとよいでしょう。

  • シーケンス図
  • 状態遷移図
  • 樹形図

 Akkaを用いると、これらの図による設計を素直にソースコードに落とし込めます。言い換えるとソースコードを書き始める前に適切な設計を行う能力が求められます。

 まずは登場するアクターの種類を考えます。購入者アクターとチケット在庫管理アクター、そしてイベントアクターを考えましょう。イベントアクターはチケット在庫管理アクターの親となるアクターです。これらのアクターの詳しい親子関係については、後ほど樹形図を用いて改めて説明します。

 次に、シーケンス図を使ってチケット購入の流れをアクター同士のメッセージのやりとりとして表現します。以下の図のように、チケット購入の処理は、チケット購入者アクターがメッセージを受けて、イベントアクターを経由してチケット在庫管理アクターにメッセージを送り、そこから最初の送信元にメッセージを送り返す流れで処理されます。最初のメッセージ送信元は、Web APIなどアクターの外部からの入力となりますが、今は外部からの入力は考えず、アクターがメッセージを受け取った後の処理だけを意識してください。

 チケット販売開始と販売終了の処理はいずれも以下のシーケンス図で表される流れになります。チケット在庫管理アクターはチケット販売開始メッセージを受け取って初めてチケット購入リクエストを受け付けることができます。またチケット販売期間終了を示すメッセージを受け取ったら内部状態を変化させ、在庫が余っていてもそれ以降のチケット購入リクエストを拒否します。

 アクターの状態を設計するためには状態遷移図を用います。チケット購入者アクターには活性/非活性という、2つの状態があり、会員登録直後は非活性状態、クレジットカード情報などチケット購入に必要な個人情報が全て登録されたら活性状態となります。

 チケット在庫アクターはチケット購入者アクターに比べて少し複雑です。最初は販売開始前の状態で、次にチケット販売開始状態になり、購入リクエストを受け取るたび在庫数を減らします。そして在庫数がなくなると売り切れ状態に遷移します。また、在庫数が余っていても販売期間終了メッセージを受け取ると販売終了状態に遷移します。

 最後に、Akkaアクターは全てガーディアンアクターを頂点とする親子関係の中に存在するので、樹形図によってそれを表現します。下図の頂点がガーディアンアクターで、その下にチケット購入者の親アクターとイベントの親アクターが配置されます。イベント親アクターの下にはイベントアクターが、さらにイベントアクターの下にはチケット在庫管理アクターがあります。

次のページ
設計をもとにソースコードに落とし込む

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Akkaで学ぶアクターモデル入門連載記事一覧

もっと読む

この記事の著者

リチャード 伊真岡(リチャード イマオカ)

 大学卒業後、9年間証券会社にてプログラマ兼技術サポートとして勤務。その後いくつかの企業でバックエンド・エンジニアや技術広報などを務める。  プライベートでは過去にScala/JavaのOSSであるakkaへ貢献。 Twitter:@RichardImaokaJP

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/12642 2020/08/05 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング