Pixel Pedals of Tomakomai

北海道苫小牧市出身の初老の日常

今日は第15回 Cloud Application Platformアーキテクチャの日です

今日は第15回 Cloud Application Platformアーキテクチャの日です

第15回 Cloud Application Platformアーキテクチャ にお邪魔しています。

Cloud Application Platformアーキテクチャ / asami224 さん

  • ディスカッション用のスライドです
  • Cloud Application Platformのコンセプト
  • Web DSL
    • DSLという言葉は聞かなくなったが、また戻ってくる
    • アプリバブルは終わった。WEBに戻ってきた
    • WEB開発はGUI開発の歴史を繰り返しそう
    • JSは型がないのでバグがとれない。 lint は限界があるでしょう
    • ロストテクノロジーの再発見
    • markup+αでアプリを作りたい
  • 関数型プログラミングが大事になってくる
    • 商用の大きいプログラムはすべて関数型になる
    • モナドを使う。フリーモナド。 I/O モナドの拡張
    • フリーモナドを使ってState machineを実装する
  • reactive streams
    • process monadを使ってpure functionalなstate machine
    • 試しに使ってみたらうまく動いた
  • 銀行でさえもクラウドを使おうとする時代
    • AI, IoT : お客さんが欲しいと言ったら提供は必要
    • Distributed, Concurrent/Parallel, Asyncronous, Realtime : 非同期が大切
    • 例: IoT : 大量のイベントを受け取る。ファイルではなくストリームで来る
    • AIの詳細は専門家だが、大規模データを扱う必要がある。データの準備が7割。普通のエンジニアに一番大事
  • Object-Functional Programming
  • Procedural Programming, Object-Oriented Programming, Functional Programming
    • Java = OOP + PP, Lisp = FP + PP (+ Meta), Haskell = FP, Scala = OOP + FP + PP + DSL [+ Meta], scalaz/cats = OOP + FP + DSL [+ PP] [+ Meta]
    • オブジェクト指向がないと難しい
    • APIではなく、DSLとして機能を提供。モデリングが簡単になるのではないか
    • Metaも重要。コンストラクタやエンコーダ周りを自動でやらせたい
    • Scalaは文法がモダンなので、簡単にかけて良い
  • クラウドアプリケーションではFPを使っていくのが重要
    • 10年前から言っててあまり変わっていないとは言え・・・
  • FPにおける重要な概念
  • Scalaは増えてる?
    • 増えてはいる。Pythonが増えすぎた。Javaも残ってる
  • Object-Functional Analysis and Design
    • ビジネスから実装までどうつなげるのか
    • アプリケーションのモデルからプログラムを自動生成したい
    • プログラムの自動生成を受け止められる強力なプラットフォームが必要
    • 2つの伸ばし方 : 「ビジネスの方向」「上流のモデリングからプログラムの生成」
  • 数理モデルと認知モデル(ヒューリスティックモデル)
    • 認知モデル: OOPモデリングの売り。人間の見たものをそのままシミュレートする
    • 数理モデル: 自動生成に向いている
    • 二本立て。クラウドプラットフォームで実現させるには??
  • 構造データと半構造データ
    • もともと存在する不定形のデータが先にあり、それを処理するアプリが後
  • Cloud Application のメタモデル
    • UP : Static Structure Model(クラス図など)、Dynamic Model(state machine)、Collabolation Model(interaction model。ユースケースから帰納的にモデル化)
    • OMT(object-modeling technique) : Dataflow Model (FP)
      • UPで一度過去に消えたもの
      • big dataには有効そう
      • FPの台頭
    • Business Rule Model
      • AIの応用。AIはFunctionをプログラミングではなくデータから作る
      • データをどう用意するのか
      • FunctionのInterfaceは大事。ビジネスルール(例: 運賃表)
  • Cloud Application Frameworkの狙い
    • フレームワークは重要
    • 運用コスト、セキュリティ : ここまでは既存のASPと同じ狙い
    • ビジネスの振る舞いを集める
      • ログデータなどを、アプリ間で揃える
      • 最近のBigDataは、データの正規化に時間を取られている
    • 複数企業間の連携を簡単にする
      • DBを共通化する
      • 複数の企業が提携するショッピングモールなど
      • はじめから連携する気ではなかった企業間を、簡単に連携できる
    • ビジネスとエンジニアリングの共通言語
      • 別のプロジェクトから来たエンジニアがすぐ開発に入れる
      • 完全リモート。週に3時間程度しか事務所にいない
      • フルタイムじゃないエンジニアでも、会社に参加できる枠組み
    • アプリケーション開発は設定とDSLの記述だけでやりたい
      • 設定だけでもいろいろなことが表現可能
  • Coreの構成
    • Engine : BaaS + CMS + CRM + EC + Publishing
    • ServiceBus : PubSub(kinesis)によって連携させている
    • 管理コンソール、Zabbix
  • Subsystemの構成
    • JobScheduler(OSS) + ECS : ドイツ製。安定してないので考え直し中
    • PUSHSender, MailSender
    • EAI (ServiceMix/Camel)
    • Data Aggregator : RedShift, Aurola
  • 今後の展望
    • Core, SubSystem以外のシステムもぶら下げる (Application Service (仮称))
    • DMP, DWH, MDM(Master Data Management)
    • Advertisement(ニーズがあまりないのでペンディング)
    • Workflow (ステートマシンの管理に必要。Marketing Automationの基盤ともなる)
      • OSSでもあったが消えていった ... アダプタが必要で、書くのがむずい
      • 統一データにしているので、カスタマイズしなくても利用可能
  • Q). MDMは統一データでは不要なのでは??
      1. 売店で同じ商品を扱ってる場合などに必要
    • スター型のデータ構造。プラットフォームのマスタ+自社データ、という組み合わせで使っていく
  • Q). JOINするなら同じノードに載せる必要があるのでは?
    • 原則はそう。お客さんが嫌がるなら、アプリサイドでJOIN
  • WEB DSL
    • 経緯: アプリバブルが終わってしまった。WEBへ
    • WEBのレイヤでDSLにした
  • モデリングと実装の仕方
    • 今まで: domainモデルに対してMVCのモデルが必要 (RoRなら自動生成)
    • View Modelの導入 : TableやGridといったUIの単位で
      • .jade 形式に、埋め込める
      • ControllerもJSONで書ける。Platformで提供するもので十分なことが多い
      • カスタマイズはCard単位で可能
    • CardとGrid(12分割)でのUIの記述。HTMLより抽象度の高い部品
      • (例: Bootstrap4)
    • markup Engineer がアプリを作れるようにする
      • 簡単なのが売りだったはずが難しくなっている
      • 営業とMarkup Engineerがアプリを作れるのが理想 → PCPで可能になる!(設定だけでバックエンドが動く)
    • Vue.jsとかAngularとか使うとなると本末転倒
  • バックエンドもフロントもコードを書かなくても良い
  • Q). system-infoはどの部分?
      1. これはsinkと呼んでおり、変数名。View Modelを入れる
    • 画面の見た目によった設計にしている。裏のドメインは複雑でも、出せば表・リスト・グリッド
  • 製品で使おうとしたらがWEBエンジニアに拒否された
    • PHPのほうが簡単ですよ」
    • 一般に展開するのは難しいのかもしれない
  • Bootstrap4 ベースの creative-tim 社のものを使っている
  • 他のテンプレートの extend も可能 → テーマは切替可能
  • サーバサイドエンジニアのほうが刺さるかも
  • Q). componentでheader明細の表現するのは難しいのでは
      1. レイアウトファイルを定義できる。表示しようとするコンテンツを突っ込める
  • Q). WEB DSLとはJSONのこと?
    • ファイルだけで書けるのがWEB DSLJSONは好きではない
  • FPで大事な技術はモナド
    • 値・関数に、コンテキストを隠蔽できる
    • コンテキストにはDistributedやParallel、I/Oとか乱数とか時間
    • pure functionalではeffectが扱えないので本来実用的なものが書けない
    • I/Oモナドがlazy evaluationのリストを作る。インタプリタが実行してくれる
    • I/Oモナドでは用途が限られる。Free Monadはそれを拡張したもの
    • Free Monadではinter preterを自分で書ける
  • Unit of Work : transactionのざっくり版
    • unitをfree monadで作ってある
    • commit historyをfree monadで作り、 interpret 時に実行する
    • メリット: DBがなくても、 interpreter テストができる
  • 難しいのでおすすめではないが、実装してみるとわかる
  • sales_order が複雑な状態を持っている
    • confirm(悪質ユーザの除外), shipment, charge
    • charge: クレジットカードと、代引き、コンビニで状態の遷移が違う
      • 内部的に複数のステートラインを持っている
      • DBに状態を持たなければならない
    • 状態変更時に Free Monad を返す
      • transaction 境界を知る必要があると、部品化が難しい
      • transaction 境界を知る必要がなくなる
  • 状態はDBには持ってない。発生したイベントをすべて登録してあるので、状態がわかる
  • Q). 失敗したときにはイベントを残す?
    • この例ではイベントを残さなくていい場合
  • Q). transactionはどう切る?
    • 今はモナド一個で1トランザクション。プリミティブを用意すればできる。free monadのprimitiveにすでにロック管理などはある
    • デバグの難しさ、動きの予測の難しさ、が難点
    • スタックトレースを見ても何もわからない。デバッガは対応してない
  • Q). メモリリソースは?
    • フリーモナドはメモリを使うのでもともと気をつける
    • reactive streamsを使うと、大きなデータをウィンドウとして扱えるので、解決できる
    • エンジンがキャッシュをしている
  • free monad は 非同期や many core がもっと普及してから。5年後に使うかもしれない技術への投資
  • Unit of Work ではトランザクションがあるので、実行方法を変えるのはちょっとむずかしいかも
  • monoidを使うと、計算の順は気にしなくて良い。最適化できるようになる。モナドもモノイドなので
  • 代数的データ型に落とし込めば、数理モデルのいろいろが使えて、良い

windowでGCPのcloud shellを使う

windowschromeGCP の cloud shell を使おうとすると、 Ctrl-t, Ctrl-n, Ctrl-w あたりをブラウザのショートカットに食われて発狂しそうになって困ってたんだけど、 SSH for Google Cloud Platform で解決できることを知った。

ちなむと gcloud alpha cloud-shell も試したんだけど、puttyServer refused our key とか言い出して何もできなかった。実にアルファ版らしい。

cloud shell は tmux をデフォルトで有効にしてくれるのだけど、デフォルトではステータスバーを見せてくれないので .tmux.confset -g status on と書いておいたら見慣れた感じになった。

WSLのubuntuにDist::Millaを入れる

WSLubuntuにDist::Millaを入れたときのメモ。plenv、perl5.26.1、cpanmくらいまではすんなり入った。

割と試行錯誤して入れたから、他にも必要かも。

$ perl -v
This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64-linux
..略..

# Dist::Zilla::Plugin::LicenseFromModule からの依存が漏れてそう
$ cpanm JSON

# SSL関連
$ sudo apt install libssl-dev
$ sudo apt install openssl

# nonblockingのテスト落ちてるけど諦めた
$  cpanm -f --notest IO::Socket::SSL

# タイムゾーン設定
$ sudo dpkg-reconfigure tzdata

$ cpanm Dist::Milla

.NETがむずかしい

MSのエコシステムがよくわからなくていろいろ調べている。調べたのはこんなところ。

  • .NET のランタイム環境は複数ある
  • mono はCLIで扱える ( mono コマンド)
  • .NET core はCLIで扱える( dotnet コマンド)
    • というか、それぞれにコンパイラとかツールセットが付いてるんだろうけど、環境によってコマンド名などは一緒なんだろうか?
  • Visual Studio では .NET Framework のアプリを作れる
    • そして .NET core も作れる
    • android とか ios とか unity とか、他にもいろいろ対応
  • Visual Studio for Mac は mono のアプリを主に作れる?
    • こちらも、他にもいろいろ対応している
  • Visual Studio Code は基本的にはテキストエディタ
    • dotnet コマンドを手で叩いてもいい(エディタ内でターミナルが開ける)
    • 拡張入れればいろいろしてくれる
    • VSもテキストエディタ的に使えるが、基本的には .NET Frameworkのアプリを、IDEが用意しているテンプレートから書いてく、という使い方がいい感じがする
  • ビルドすると .exe.dll ができるが、Macでは monodotnet コマンドでランタイム経由で実行する
  • プロジェクトはアセンブリ( .dll または .exe )と同じ粒度。それを、ソリューションでまとめてアプリとしてビルド
  • アセンブリは言語( C# F# に関係なく使える)
    • これは強力だと思ってるが、まだ試せてない
  • ビルドに必要なファイルが多そうな気がする?
    • .fsproj ファイルとか、他にも必要?
    • Visual Studiodotnet コマンドが隠蔽しててあまりわかってない
  • ビルドに関しては、 F# だと FAKE.exe とかある (まだ使い方調べてない)
  • F# の基本ライブラリは関数型チックな部品がほとんどなので、基本的には C# と同じ BCL (というか .NET Standard でいいのかな?) を使う・・・気がする
  • どんな環境もそうだけど、道から外れるとハマる
    • WebSharper の VS用テンプレートを .NET core で使おうとしたり
    • VSC + Ionide の テンプレートが macOS で動かなかったり
    • Windows上でVSでC#の開発をする分にはハマらないんでしょう、という勝手な前提の上の感想だけど

なんか間違えてそうな部分もあるなー。そもそも C# と CIL を Java.class ファイルだろくらいにしか思ってないのだけど、さきにそっちをきちんと把握すべきなのかもしれない。

F#とUnityを学んでいる

せっかくWindowsマシンを使っているのだからMSの開発環境のエコシステムにどっぷり浸かってみたいと常々思っていたのだが、ようやく最近触り始めた。

まず、F#については Beginning F# 4.0 を読んでいる。F#はOCamlをベースにしていると聞いていてずっと興味があった言語。改めて学んでみると、あー、Haskellって後発の強みでsyntax改善されている部分も多いんだなあという印象は受ける。が、まだまだ序盤の面白くない部分なので、もっと読み進めるとがらっと印象が変わりそう。

www.apress.com

UnityはWindowsで触る必要はないんだろうけど、C#つながりで興味が出たのでチュートリアルをやってる。

unity3d.com

大昔に触ってたSDLやら生OpenGLとは全く違ってGUI作るIDEみたいな感覚になってて、ゲーム開発こんなんになってるのかーって感動がすごい。ローレベルなレイヤを触らずに最初からゲームの中身を考えられるのは魅力的だが、低レイヤでゴリゴリ最適化するのがゲーム開発の醍醐味ではという気もするので、ちょっと複雑な気分ではある。

Visual Studioで開発していた人が他のIDEをめっちゃDISるのを何度も目撃しているので、Visual Studioがどれだけ便利なのか知っておきたいというのもWindowsの開発環境を触り始めた動機である。が、残念ながら今のところ全く美味しさがわかってない。なにか良い資料を探して、それに沿って良い使い方を覚えたほうが良さそう。