過日、株式会社セプテーニ・オリジナルさま主催の「新宿 Geek Lounge#2 Scala Meetup」に参加いたしました。
元Typesafe/Lightbend社Akkaエンジニア、現スターバックス社でディレクターをされているJamie Allen氏が、日本向けRewards Program（ある種のポイント制度）の開発の仕事で来日しており、この機に"Future of Reactive Architectures"とのタイトルで講演いただくとのことでした。
今回は主催者さまによって通訳の方も配置いただきました。通訳の方のスキルレベルについては特記する必要があります。関数型プログラミング、リアクティブ・システム、チームビルディングとマイクロサービスの関係性、など、現在のITに関わる概念の中でも特に高度な部類のものが連発な講演です。通訳後の日本語を聞いていると、明らかに用語や文脈を理解されていて、日本語で言い回しの補完が入ったような訳になっていました。質疑応答でも、曖昧な文での質問の要点を的確に受け取っていただけました。聞くとScalaMatsuriのときに同時通訳などをお願いした会社さんに今回もお願いしたようです。
・
主催者さまによるブログ記事です。
Jamie Allen氏の講演資料です。
・
以下、私が興味を持ち、理解したポイントの備忘録です。（※私のフィルターを通っていますので、以下の記載はJamie Allen氏の講演意図通りではないかもしれません。また、懇親会で個別に伺った内容も含みます。（※私の出川イングリッシュ級の英会話、というより“英単語列”に辛抱いただいた氏に感謝しなければ。。））
・あまりにも高度な技能者（だけ）による高度なチームができてしまうと、そのようなかたちで属人化してチームの持続性がない。
・あまり沢山の要素技術を導入すると、運用が複雑になるので避ける。DBにはCassandraだけを用いている。（AWSで運用しているが、）Amazonの固有のRDS、Dynamo等は一切使っていない。Akkaも、ステートレスなロジック置き場としてのみ。（ステートフルなアクターとしては用いていない。）
・「RDSやDynamoを使わない」にはセキュリティ・ポリシー上の理由もあって「第三者の管理下にあるDBにデータを預けるなんて、とんでもない」という判断がある。
※S3すらも使ってないのだろうか？でもポリシー的にそのはず。
・その一方、開発・テスト・配置に関わるツール類は充実させている。誰でも、再現性高く実施できるように。
・"Security by Design"大切。
・ロジック・ノード間のつなぎは、すべてgRPC/HTTP。依存先が遅くて、あるいは落ちているかもしれないことを前提とした設計・実装については、メンバーに強く意識させた。ここに関わる"Pain"は克服してもらった。
※Akkaで、その通信がgRPCってことだろうか？？
・DBの設計には、Append-Only＝Event-Sourcingを盛り込んでいる。Cassandraに、書き込みマスター・ノードと複数種類の読み込みビュー・ノードを作り込んでいる。転送ロジックは個々に設計・実装、それなりに複雑。
まとめると、、
- 用いる要素技術は平易にかつ種類を少なくして、日々の開発・運用へ参加する者に対する学習コストが上がらないようにする。
- その一方もしくはそのために、開発・テスト・運用の支援ツールは積極的に充実させている。
- ただ、分散環境下でのシステム特性、それに対応したプログラム／プログラミングの在り方については身に着けてもらった。
- また、開発・テスト・運用の支援ツール群をどう構成するかという点と、DBを含む分散環境にあるシステム・アーキテクチャの設計はそのものは、それなりに高度に実施。
◇
ところで、Allen氏が最初から最後まで強調していたのは、「高度なテクノロジーなんて、ビジネスへの貢献が果たせていなければ、全くなんの価値もない」ということです。
このような観点は重々承知しています、頭では。しかし、どうしてもテクノロジーそのものが目的になってしまう、どうしたって面白いから。「ビジネス貢献」って言葉では分かっていても、実践的にはどんな心持ちでどんな優先順位でどんな評価軸でやればいいのか？
究極のテクノロジーベンダーから至高のユーザー企業へ移籍した氏がこのような話をされるだろう事を、もしかしたら私は初めから期待していたように思います。
・
Allen氏の云うところの話（※上で、まとめとしてボールドで列挙した事項）は、自分の中の課題感に突き合わせて、以下のような背景的課題に立脚している様に思いました。
・（システムが提供する）サービスの持続性・継続性・Continuityを担保することを考える。
・そのために、システム自体が持続的である必要がある。
・システムも人が支えるのだとしたら、開発チームの持続性も考えなければならない。
無理に難度の高い技術で基盤を構成すると、それ自体の障害や運用ミスの確率が高まります。いわゆる“枯れた技術”に寄せることでそれを避けます。高度技能者に依存すると云うかたちの“属人化”も避けます。高度技能者に依存していると希少人材獲得がサービス維持の前提条件になってしまいます。
Allen氏の実践にてなかなか難しく思えるのは、そのように「平易で枯れた要素技術を用いて平均レベルの技術者で回せるようにする」と言いつつも、その一方で、「ロジックの分散化」、「DBまわりのR/W分離とEvent Sourcingによる連携」、「そういった分散環境に必要な運用」、これらの設計には手を抜いていないのです。つまり総じて、アーキテクチャーの設計、カタカナ語で「デザイン」と言った方がニュアンスがよいでしょうか、“システムの在り方に関する枠組みのデザイン”については、極めて高度に実施しているのです。さらに、メンバーがこれらの「デザイン」を理解するのに"Pain"があったとしても、それは克服してもらっている、とのことです。「実装の前提は平易にするが、設計もしくは設計意図は理解してもらう」ということなのです。
◇
＜追記１＞
あるいは、、運用設計先行で考えよう、というアプローチもよいかもしれません。「そのミドルウェア、如何に運用出来るだろうか？」と。「モニタリング要件を定めてから、それを満たす用にミドルウェアの扱いを決めていく」のも良さそうです。
＜追記２＞
さて、本記事投稿し損ねている間に、スターバックスのRewards Programが始まりました。私もiPhoneアプリ入れて、登録しました。
クレジットカード登録して、オートチャージ対応のプリペイドなんですね。Jamie Allen氏は“銀行”と表現してました。そして、スタバファンのみなさん！11月から、Web登録したプリペイドので払わないと、"One More Coffee"が150円になってしまいます！登録したプリペイドので払えば100円のままです。
◆以上
