この記事は、Elixir Advent Calendar 2023 シリーズ11 の12日目です
昨日は、@GeekMasahiro さんで 「Elixir AtCoder用テンプレート」 でした
piacere です、ご覧いただいてありがとございます 
今年8月に開催した「ElixirImp#34：Elixirでマイクロサービス & エッジコンピューティング」 の内容（下記スライド）をコラム化しつつ、Elixirでの実践も解説していくシリーズです
目次としては、こんな感じで、今回は「01」～「04」に触れつつ、Elixirのマイクロサービス化／反マイクロサービス化に使える機能を紹介したいと思います
あと、このコラムが、面白かったり、役に立ったら、
をお願いします
改めてマイクロサービスとは？…なぜ流行ったのか？
マイクロサービスとは、小さなサービスを組合わせて1つのアプリケーションを開発するアプローチです
2013年に、アジャイルの始祖であるeXtreme Programmingを企業として初期に取り組んだThoughtWorks社のジェームス・ルイスが「Micro services - Java, the Unix Way」で初出し、2014年に、やはりアジャイル／eXtreme Programming界隈では超有名人のマーティン・ファウラー（名著「リファクタリング」「PoEAA」の著者でもある）と共著で「Microservices」にて提唱し、世に広まり始めました
ちなみにマーティン・ファウラーは個人的に22年前、eXtreme Programmingでケント・ベック（XP提唱者）やエリック・ガンマ（VScode／Junit／Eclipseコミッター）と共に彼に心酔し、私の4番目のプログラマ／エンジニア師匠と勝手に思っています 
クラウドやスマホ、SPA、API、そしてスタートアップの普及が後押しし、マイクロサービスは広く流行ったと考えられます
最近、マイクロサービスの良い噂は聞かないが…
提唱から10年近く経った最近、マイクロサービスのメリットよりも、デメリットが強調されるシーンが増えてきました
では、マイクロサービスは「使えない」のでしょうか？ … いえ、そうではありません
問題は、「マイクロサービスが本当に必要なシーン」で使えていなかったり、不必要にマイクロサービス化していることにあると考えます
つまり、マイクロサービス自体の問題では無く、単に「選定ミス」や「雰囲気で導入した」という要素が、マイクロサービスの良い噂を聞かない背景の大半では無いかと捉えています
「選定ミス」の1つとして代表的なのが、共通基盤として構成すべき対象を、マイクロサービスとして構成したが故に、システムが複雑化した … というケースが世界的に発生しており、現在、そこに対するアンチテーゼとして、「反マイクロサービス（deMicroService）」や「アンチマイクロサービス」というムーブメントすら起こっているような状況です
国内でも、先駆者たるSTORESやクックパッド等でも、こうした動きが存在します
何事も、大事なのは「正しく使う」ことであり、マイクロサービスも正しく使えば、サービスグロースの良き味方となります
「マイクロサービスパターン」とは？
マイクロサービスパターンとは、マイクロサービスでの解決策やデザイン原則をまとめたものです
「Microservices.io」 が全体図を示してくれています
https://microservices.io/patterns/
マイクロサービスパターンには、カテゴリごとのプラクティスがあります（なお、最新のMicroservice.ioの方も更新されているため、スライド／本コラムと最新図にはギャップがあります）
- アーキテクチャの問題領域
- Monolithic Architecture
- Microservice Architecture
- Database per Service
- サービス分割の問題領域
- Decompose by Business Capability 業務毎に分割
- Decompose by Subdomain…サブドメイン毎に分割
- メッセージングスタイルの問題領域
- Remote Procedure Invocation … 同期RPC（REST、gRPC等）
- Messaging … 非同期メッセージパッシング
- 信頼性の問題領域
- Circuit Breaker … レスポンスにタイムアウトを設定
- サービス・ディスカバリーの問題領域
- Self Registration … プロセス生成時に名前登録
- Client-Side Discovery
- 3rd party Registration … 代理で名前登録
- Server-Side Discovery
- トランザクショナル・メッセージングの問題領域
- Transactional Outbox
- Polling Publisher
- Transaction Log Tailing
- データ整合性の問題領域
- Saga
- ビジネスロジックデザインの問題領域
- Aggregate
- Domain Event
- Domain Model
- Event Sourcing
- Transaction Script
- クエリーの問題領域
- API Composition
- CQRS (Command Query Responsibility Segregation)
- 外部 API の問題領域
- API Gateway
- Backends for Front-Ends
- 自動化テストの問題領域
- Consumer-Driven Contract Test
- Consumer-Side Contract Test
Service Component Test
- セキュリティの問題領域
- Access Token
- 横断的関心事の問題領域
- Externalized Configuration
- Microservice Chassis
- 監視の問題領域
- Health check API
- Log Aggregation
- Distributed Tracing
- Application Metrics
- Exception Tracking
- Audit Logging
- デプロイの問題領域
- Language-Specific Packaging Format
- Single Service per Host
- Deploy a Service as a VM
- Deploy a Service as a Container
- Sidecar
- Serverless Deployment
- Service Deployment Platform
- Service Mesh
- リファクタリングの問題領域
- Strangler Application
- Anti-Corruption Layer
マイクロサービス向きなElixirの特徴
Elixirは、言語仕様および言語ビルトインで、分散／並行・並列に特化した実行単位とメカニズムを揃えており、マイクロサービス構築／解体に重い腰を上げる必要が無い点が強みです
また、クラウド無しでもエッジコンピューティングが構成できるレベルの機能が標準搭載な点も強みです
スレッドセーフ対応が根本から不要なプロセス／メッセージパッシング構造（アクターモデル）であり、それがローカルマシン内だけで無く、リモートマシン間にも透過的に展開できる点も、Elixirの強力な強みです
並行・並列環境下におけるデータ処理に特化された言語／FW仕様も、ユーザー数やデータ量がかさみやすいマイクロサービスに有利な点として挙げられます
大半がElixir標準搭載機能で賄える
具体的なElixir機能を挙げていくと、下記の通りです
①～④、⑥～⑧、⑩～⑪は言語標準搭載機能で、その他も、Elixir界隈では準標準急のメジャーなフレームワークになります
終わりに
Elixirとマイクロサービスの相性の良さが、何となく雰囲気だけでも伝われば幸いです
次回は、下図のように、マイクロサービスパターンとElixir機能をマッピングした上で、具体的なマイクロサービス／反マイクロサービス構築について解説します
明日は、@GeekMasahiro さんで 「ElixirでAtCoder 入力処理の高速化（ABC309 Eで試す）」 です
p.s.このコラムが、面白かったり、役に立ったら…
にて、どうぞ応援よろしくお願いします