前半: OSSコントリビューションの始め方 マーベリック株式会社 リチャード伊真岡 出張Akkaワークショップ @ atWare

No content

OSS貢献にハードルを感じたことある人いますか？ 英語、普段使ってないプログラミング言語に挑戦したい、たまたま遭遇したフレームワークのエラー直 したいけどソース読みたくない…等など

やり方は人それぞれ ● 私はドキュメンテーション更新が8割から9割 ● ボーナスチャンス(簡単なイシュー大量発生)が2回ほどあった ○ #23052 #20288 ● Pull Requestが主、Google Groupsやgitterは無視 ● 数ヶ月コミットしなかった後復帰を繰り返す ● 今は過去一年くらいコミットしてない、スタンスが変わった

コントリビューションのパターン ● メインコミッタになる ○ たくさんコミットできる ● 仕事で使うOSSの問題を直す ● 自分が興味が持ったものに貢献する ○ 選択の幅は広い 複数同時でもよいし始めたらいつやめても良いので気軽に。

コントリビューションのパターン ● 自作OSS ● 他人の小規模OSS ● 大規模OSS 先程の「自分が興味を持ったものに貢献する」なら、おすすめは大規模OSSの中か ら貢献しやすそうなものを選ぶ。理由は情報量が多い、開発が活発、長くやると 基礎の勉強になるなど。ただし、複数同時でもよいし始めたらいつやめても良い ので気軽に。

いろんなOSSを試して止めよう 自分にあったやり方をじっくり探す

私が思うコツとよい心構え ● 他人の意見は役に立たない、マウンティングとドヤは無視 ○ 自分の仕事の負荷、余暇時間、技術力、英語力すべてが他人とは違います ● コミット数を稼ぐゲームでもよいしコミット数以外で活動するのも良い ● GitHubでHelp Wantedタグをみる ● 頼れるだけ他人を頼る、一方で頼れない(気持ちの問題含む)ときに乗り越え る方法をもつ ○ 環境構築・再現のスピード重要、ドキュメントやソースコードに当たりをつけて読む能力 ● 英語は重要、どれだけ時間を割くかは難しい問題

コントリビュートしてみたいOSSある人います？ 実際にGitHub issues見るとおもしろそう

後半: Akkaについて マーベリック株式会社 リチャード伊真岡 出張Akkaワークショップ @ atWare

Akkaの歴史とモジュール(派生プロジェクト) akka-actor 2009 (1.0), 2012(2.0) Erlangにヒントを得る spray 2011 akkaを利用した初期のプロジェクトの一つ akka-cluster 2012 複数マシン akka-persistence 2013 actorが落ちたとき対策、Event Sourcing akka-streams, akka-http 2015 sprayの課題を解決、back-pressure akka-cluster-sharding 2016? clusterが真の威力を発揮 akka-typed 2018 3度目の正直

No content

1973～ ● 最初「人工知能」とか actor model https://www.semanticscholar.org/paper/A-Universal-Modular-ACTOR-Formalism-for-Ar tificial-Hewitt-Bishop/208aee805004d575035284b1c232209e9fa26b0e This paper proposes a modular ACTOR architecture and definitional method for artificial intelligence that is conceptually based on a single kind of object: actors akka-actor 2009～ ● shared mutable管理 ● high performance ● fault tolerance

Akkaの歴史とモジュール(派生プロジェクト) akka-actor 2009 (1.0), 2012(2.0) Erlangにヒントを得る spray 2011 akkaを利用した初期のプロジェクトの一つ akka-cluster 2012 複数マシン akka-persistence 2013 actorが落ちたとき対策、Event Sourcing akka-streams, akka-http 2015 sprayの課題を解決、back-pressure akka-cluster-sharding 2016? clusterが真の威力を発揮 akka-typed 2018 3度目の正直

2011～ ● 初期akka利用プロジェ クトの一つ ● high performance ● magnet pattern ○ 後のakka-http routing ● 後々akka-httpへ

akka-http, akka-streams 2015～ ● sprayで解決できな かった問題 ● back-pressure ● akka-streamsから alpakka https://www.youtube.com/watch?v=y_slPbktLr0

alpakka ● 豊富な接続先 ● akka-streamsとデータ ソースをつなぐ ● Enterprise Integration Patternsにおける既存ソ リューション置き換え? https://doc.akka.io/docs/alpakka/current/index.html AMQP Apache Camel Apache Cassandra Apache Geode Apache Kafka Apache Kudu Apache Solr Avro Parquet AWS DynamoDB AWS Kinesis AWS Lambda AWS S3 AWS SNS AWS SQS Azure Event Hubs Azure IoT Hub Azure Storage Queue Couchbase Elasticsearch Eventuate File FS2 FTP Google Cloud Pub/Sub Google Cloud Pub/Sub gRPC Google Cloud Storage Google FCM gRPC Hadoop Distributed File System - HDFS HBase HTTP IBM Bluemix Cloud Object Storage IBM Db2 Event Store InfluxDB IronMQ JMS MongoDB MQTT MQTT Streaming OrientDB Pulsar Server-sent Events (SSE) Slick (JDBC) Spring Web TCP UDP Unix Domain Socket

Akkaの歴史とモジュール(派生プロジェクト) akka-actor 2009 (1.0), 2012(2.0) Erlangにヒントを得る spray 2011 akkaを利用した初期のプロジェクトの一つ akka-cluster 2012 複数マシン akka-persistence 2013 actorが落ちたとき対策、Event Sourcing akka-streams, akka-http 2015 sprayの課題を解決、back-pressure akka-cluster-sharding 2016? clusterが真の威力を発揮 akka-typed 2018 3度目の正直

akka-cluster 2012～ ● 早い段階からakkaは分散 システムを意識 ● fault-tolerance ● performance(scalable)

val region: ActorRef = ClusterSharding(system).shardRegion("MyActor") region ! Message(“id_123456”) akka-cluster-sharding 2016?? ～ ● Actorのclass名とIDさえ分かっていればメッセージを送れる手軽さ

akka-management akka-discovery 2018??～ ● clusterのseed-nodesが めんどくさい問題の解決 ● Kubernetesなどの上で akka-cluster構成 ● Kubernetesはakkaを知ら ないのでakkaのプロトコ ルでメッセージを送るた めに2段階のクラスタ akka-cluster kubernetes

Akka Clusteringハンズオンやりたいなー

Akkaの歴史とモジュール(派生プロジェクト) akka-actor 2009 (1.0), 2012(2.0) Erlangにヒントを得る spray 2011 akkaを利用した初期のプロジェクトの一つ akka-cluster 2012 複数マシン akka-persistence 2013 actorが落ちたとき対策、Event Sourcing akka-streams, akka-http 2015 sprayの課題を解決、back-pressure akka-cluster-sharding 2016? clusterが真の威力を発揮 akka-typed 2018 3度目の正直

akka-persistence ● command sourcing, event sourcing ● 必ずevent履歴がある ○ トラブルシュート、audit trail ○ MySQLの例、履歴データモデリングの難しさ ● トランザクションスクリプトの回避 ● パターンとして利用できるツールが 揃っていることがよい

MySQLの履歴 ● バイナリのログなので 閲覧はちょっとつらい

MySQLの履歴 ● バイナリのログではなくevent履歴 テーブルをつくるとテーブル定義に 苦労するかも ● そもそもリレーショナルモデルは履 歴データのモデリングが難しい

No content

actor, cluster, streams actor, persistence actor actor, persistence, cluster akka-http, streams, alpakka

AkkaとSpring Bootの共存

Akkaの強みと使い所 ● actor + cluster-sharding + persistence ○ フルパワー あるいは ● akka-httpのみ ● akka-streamsのみ、データ分析用途やバッチ処理 ○ alpakka

これはホワイトボード使って対話的に図を描いた方が いい気がする AkkaとSpring Bootの共存

akkaのない世界を仮定するとどんな構成を組む？

akkaのない世界を仮定するとどんな構成を組む？ ● stream処理はkafka stream? がどこまで使えるか ○ kafka streamはkafka -> kafkaのストリーム ● alpakkaの代わりにkafka connect? ● spark streamingはまるで別物 ● シンプルな表現ができるならGoogle Dataflowあたりに全振りでも良いのかも ストリーム処理

LightbendがAkka Stream, Kafka Stream, Spark Streamの比較や組み合 わせ方を紹介している Webinarがたくさ んある おすすめはコレ、でも複数見ると良い “Streaming Microservices with Akka Streams and Kafka Streams” https://www.youtube.com/watch?v=6HkVDQhl2L E&t=450s

akkaのない世界を仮定するとどんな構成を組む？ ● reactiveXやvert.xでevent drivenな処理は書ける ● event sourcingやCQRSは難しくなりそう ● cluster-shardingについては諦めないといけないと思う、ステート「フル」なアプリ ケーションは書かないほうが良い ● 結局データはデータベースに入れるならそこを中心にどう扱っていくかというよく ある話題になる？ サーバー型アプリケーション (モノリス、マイクロサービス)

LightbendのCTO Jonus Boner氏はステート「フル」な マイクロサービスを提唱している 普通サービスはステートレスな方が扱いやすいし落ち ても大丈夫だし、他ではあまり聞かない方針だと思う “How To Build Stateful, Cloud-Native Services With Akka And Kubernetes” https://www.lightbend.com/white-papers-and-reports/stateful-cloud -native-services-with-akka-and-kubernetes “Serverless Needs a Bolder, Stateful Vision” https://thenewstack.io/serverless-needs-a-bolder-stateful-vision/

Lightbend Fast Data platform