The Swift Server Work Group (SSWG) の目的は、Swiftでのサーバーアプリケーション開発の安定した健全なエコシステムを作ることです。 現在フォーカスしているのは、コミュニティが信頼できる高品質で十分にメンテナンスされたライブラリやツールの開発を促進することです。 このトークでは、2018年9月にSSWGが発表されて以降の最近の開発を振り返ります。 オープンになっていなかったプロセスや参加する方法、コミュニティとチームが行なっているプロジェクトやプロポーザルの詳細について説明します。
Swift Server Ecosystemについて見ていきたいと思います
なぜSwift on Serverを使うのか。
人にとっても良い、デベロッパーも大好き、安全、エクスプレッシブでローレベルからハイレベルまで対応できる、コードシェアリングにも便利。
マシーンにもいい。
ガベージコレクション不要なのが気に入っています。
リソースが競合する問題が発生するがSwiftにはその問題がない
いくつかユースケースがある
IBMプラットフォーム、Vapor、Amazon（ビデオプロセッサーパイプライン）、Appleも小さなものから大きなシステムまでプロダクトに使っています。
Opensource
Kitura,Vapor、、、Appleからいくつかライブラリが出ています。FoundationDB、その他にもGoogleと一緒にGRPCがあります。
そして真ん中のロケットマークがSwiftNIO、去年このステージでアナウンスされたものでした
ここまではいいですよね
ではこれが自分にとって正しいものなのか。既存のシステムがあると思いますが、こたえは、Yesです。しかしまだまだ開発中のものがあります。
DBとのやり取りが必要になってくる。DBドライバの状態はいろいろなものが混在してたくさんある。
Cと組み合わされた勝ちがあるということでCクライアントに対応しているのでそれを活用できるということはあるが足りないものがある、一貫性が足りない。
全体として一環とした同時実行モデルが存在していません。
WebがブロッキングでDBがノンブロッキングだとうまくいきません。逆もそうです。
ノンブロッキングの場合にどういう種類のプログラミングモデルでどのFeatureなのか、色々なモデルが必要
あと可観測性がとても重要
システム全体として中を見ることができるようにする、全体を見ることができるようにする。
ロギングがまず１つ。テキスト情報で何が起きたか全部見ることが出来雨量にする。システムが大きくなったときにいろんなコンポーネントがロギングしている。一貫性が重要。いろいろなライブラリ、コンポーネントがあるなら同じようなロギング体制が必要。メトリクスも数字的な情報とか文脈を反映する情報、パフォーマンスなどをあつめる。すべてのコンポーネントの情報を一箇所に集めて表示したくなりますよね。
それから追跡、システムを流れてコンポーネントに飛んだときにトラッキングできなければなりません。大きなシステムでは追跡が難しいのでTracingの仕組みが必要になる。ヘッダやエンベロープなどキューのペイロードにつくものですね。
必要なレベルの統合がなされていないのでバラバラのところがあるのでもう少し一貫して統合する必要がる。
Dockerも重要ですよね。macBookを使っていますが本番はLinux。コードのスプリットがあるかもしれません。本番のエミュレーションにはDockerが有効に働く。
IBM、Apple、Vaporで行ったServerWorkingGroup
Swift言語そのものの外の部分、Networking、HTTP、セキュリティに関する部分、こちらはSwiftNIO
今足りないものを足している
分散システムイベントドリブン、、、
Evolutionと似ている
ピッチから投票、プロポーザル、それが終わってインキュベーションプロセスに入る。
ライブラリが３つのレベルで受け入れられた段階。
いくつか対応しているプロジェクト
Developerが特定のSwiftバージョンをDockerベースで実行できるようにしたい
コミュニティの努力で発展してきた
いまオフィシャルな場所としてAppleのGithubに入っています。素晴らしいコミュニケーションでこのようなことをコミュニティで今後も進めていきたい
ロギングの部分、
何が重要か、アーキテクチャーです。他のライブラリ、フレームワークをもってきたときにどこにログを送るか知らなくていい。
アプリケーションオーナーがそれを決めることができる。
全体の一つとして観測性を提供することができるが、すべてAPIベース。
これは他のエコシステムの体験からもってきたもの
ロガーがミューテーションする。typesystemを活用する。ロガーはvalue type
全部のシステムを変えるのではなく
auto closureを使う
ログを送ることを遅らせることができる
常に送るとパフォーマンスコストが高い
ログを取らなければいけないときは評価することができる
メトリクスはまだプロポーザルフェーズです。
構想は似ています。API、メトリクスライブラリは切り分けられている。様々なシステムからメトリクスを見ていく。
ライブラリは分けられているので、これによってライブラリは情報を、たとえばHTTP、Webフレームワークであれ、使っていただくことができる。個々ではこのメトリクスがどこに行くかを決めるのではない、これが重要な要素に成る。
どういうコードが書かれるのか
Counterに対応している
モノリシックに増分していける。
もう一つ、タイマータイプ
リクエストにどれくらい時間がかかっているのかという評価ができる。
タイマーの形が非常に面白いのは、量化をしていくときに使うことができる。
DBだとか、あるいはピークアワーオフピークアワーで変わっていくが実際に99%タイルがどうかというときにつかえる
汎用的なReorderタイプが有る
ヒストグラムであればこうしたものがバックグラウンドのモデルとして使える
ゲージも使える
DBクライアント
PostgreSQLドライバを使ってSwiftNIOとのコンカレンシーモデルを作った
Redisで同じようなことをしようとされています。
ネットワークライブラリ
新しいバージョンリリースしました
SwiftNIOは主要な変更は５との協業性
エコシステムのアンブロックをしてオンボーディングしていただきたいということで大きなバージョン変更。
HTTP/2も比較的大きな変更がありました。基本的に書き直した。
Cライブラリベースだった。結果的にパフォーマンスをみていてCライブラリではないだろうということでSwiftで書き直しました。
SSLも前のバージョンから変わってきました
Boring？SSLに寄ってできるようになったのがSwiftPM
SwiftNIOベースアプリケーションのモビリティを高めた
皆さんの参画をお待ちしています
問題点、改善点などをお寄せください。フォーラムでいろいろな話があります
色々ライブラリを書いていただきたいものがあります。
月次でSwift Linux Releaseが行われています。ぜひ皆さんにもご参画いただきたいと思います。
ありがとうございました。
