UD Day 15 アーキテクチャーの検討10(NW速度を測る)

最終的なデプロイメントモデルを検討する際の一つの材料とするためにNWの速度を測ります。具体的には、GCPのとあるリージョン内の同一Zoneもしくは異なるZoneのそれぞれのケースでNW速度の実測がどの程度異なるかを測ります。

前提: n1-standard-4 (4コアのもの)。OSはgcloud computeコマンドで作成されるデフォルトOS(Debian-9)を利用。同一内の場合、asia-northeast1-aを利用、異なるZone内で同1-aおよび同1-bを利用。
試行内容: 各ケースにおいて、サーバー側、クライアント側に分け、それぞれiperf3コマンドを実行する。

同一Zone内、異なるZone内での測定結果

Zoneをまたぐ場合に、約24%程度の劣化があることがわかります。このことは、DBサーバーとしてCassandra(ScyllaDB)を採用したことによって、重要となります。特にfull repairと呼ばれるノード間の整合性を修正するジョブを行う際に、非常に多くのI/O、NWトラフィックが発生するため、これをいかに早く終わらせるかという観点でNWのパフォーマンスが重要になります。
DBノードをマルチゾーンとする場合の性能劣化24%であり、これは少なくない数字なので、同一ゾーン内を選択しました。
以下は、実際の計測ログです。(続く)

同一Zone内の施行(サーバー)
同一Zone内の試行(クライアント)
異なるZone間の試行(サーバー)
異なるZone間の試行(クライアント)

UD Day 7 アーキテクチャーの検討2(クラウド・サービス)

Day6に引き続き、アーキテクチャーの検討を行います。アーキテクチャーの検討と言いつつ、主たる内容はコストの比較です。想定するスペックに対して、どの程度のコストかを比較しています。
最終的には、GCPを採用しています。その理由は、Live Migration、自動割引(個人的にReserved Instanceの考え方が好きではない)、詳細なスペックを見た際のコストパフォーマンスからの判断です(当時の判断)。既に優位なポジションを気づいているAWSに対して他のパーティが価格を含めた別の面で価値を訴求するのは当然なので、その面で考えても、他のクラウドパーティも検討することは合理的だと思います。
主に金融系などの基準が厳しい業界であれば、業界基準やISOへの準拠状況なども参考にすべきかと思います。

実際の比較表は以下の通りです。いずれも東京リージョンで、当時のドル円レートとして1ドル=110円で計算しています。

GCPにおけるコスト比較
AWS、Azureのコスト

大まかにGCPのGCE、AWSのEC2、AzureのVMを比較すると大凡同等スペックではGCEが優位性があると判断しました(上記のGCEの表にはLoad Balancerのコスト(=負荷分散の項目)を含めているのでこの分は割り引く必要があります)。厳密には、更にGCE以外のサービスについても比較が必要ですが、ここでは割愛しています。尚、クラウドパーティ以外の第三者がサービスを提供している場合は、割引がある場合があるので、この限りではありません。

次にGCPの中でどういうサービスを使うかを検討する場合、以下のような点がポイントになると思います。
 a. OS以上をすべて自社で管理する(GCE)vs極力アプリ層に注力する(GAE)
 b. 想定するサービスレベルを満たす可用性か(何%以上の稼働率を想定するか)
 c. Docker/Kubernetes(GKE)を採用するか(aとも関連)

aについては、後者の方が高くなります。コスト比較の結果、GCEにしました(その分、構築コストが必要になります)。

bについては、最新の情報を参照すると、各サービスごとの違いはあまりないようです。全体の可用性を更に考える場合には、同一のインスタンスを複数稼働させる、別Zoneにそれぞれ複数インスタンスを稼働させるなどのことを考える必要があります。
c.f.)稼働率を考える場合の参考値
  ・95%・・・・・・・18.3日
  ・99%・・・・・・・87.6時間
  ・99.9%・・・・・・8.76時間
  ・99.99%・・・・・ 52.6分
  ・99.999%・・・・・5.26分

cについては、DBサーバーを考える場合、当時の時点(2017)では、Dockerの選択は効率性の観点から採用を考えられず(*)、組むとしたら、APサーバーをGKE、DBサーバーをGCEという方式でした。構成ファイルを作り、管理していく場合に、それぞれのスキルが必要であり、2種類のファイル群を管理していくことになり、効率的ではありません。このような、観点から、GKEは様々な点で魅力があったものの、採用しませんでした。
いずれにせよ、Dockerの利用が強い分野はStateless=アプリ系な分野であったので、Stateful=DB系については、無駄なオーバーヘッドがないかを調査しておく必要があると思います。

(*)…後々の工程でも出てくるかもしれませんが、DBサーバーとしては、最終的にScyllaDBを採用しましたが、当時の時点では、Docker上で構築した場合のパフォーマンスが悪いという報告がありました。Cassandra系のモノの本にもそのような記載があります。現在見てみると、Docker HubにScyllaの公式のイメージがあるので、これを試してみるのはありだと思います。

参考リンク)
GCEのSLA

UD Day 1 問題と解決策(仮説)

0.はじめに
2019年の3月頃にコメントできるブラウザUDをリリースしました。ダウンロード数が芳しくないのが残念ですが、このシステムの設計や用いた技術・アルゴリズム等の詳細について、どなたかの参考になればと思い、書き起こすことにいたしました。
Dayいくつまで行くか分かりませんが、全体のシステムを網羅しようと思うとなかなかの量になると思います。

Apple Storeのリンク)
https://apps.apple.com/us/app/ud/id1454147581

尚、箸にも棒にもかからなかった場合、コードについてもすべてオープンにしようと思います。

1.概観
UDは、モバイルのブラウザとAPIシステムから構成されています。ブラウジング(ウェブサイトの閲覧)の度にAPIシステムに対するトランザクションがバックエンドで発生するため、多数のユーザーによる利用を考えた場合、超スケーラブルである必要があり、それ故にハイパフォーマンスである必要があります。
超スケーラブルであるためには、いくつか検討すべき項目があります。例えば、DBサーバーです。旧来のRDBはRead-Onlyのレプリケーションされたノードを持つことにより分散性を高めていますが、Writeするノードのパフォーマンス・キャパシティ上の限界値がWriteの制限になります。つまり、WriteもReadも分散するには、これでは満たしません(ただし、最新の情報としては、RDBでも上記要件をみたすものはありそうです。ですが、これにはコストの壁があります。全てはコストとのバランスに尽きます)。
このようにウェブシステムに一般的に見られる典型的な構成では難しく、今回超スケーラブルなシステムを作りました。と言っても世の中にあるプロダクト群を使ったものです。
この一連の連載により、以下の分野について、参考になると思います(順不同、参照する内容の一部)。ご意見もあれば、忌憚なくいただければと存じます。

・スケーラブルなシステムのアーキテクチャー
・複数リージョン(GCP)において分散するシステム
・Cassandara/ScyllaDB
・Ansibleによる自動構築
・gin-gonicによるウェブシステム
・iOS〜APIサーバー間のHandshake

2.問題と解決策

冒頭が長くなりましたが、Day 1の本旨は、なぜこれを作ったか、です。我々は、以下の問題と解決策を仮定しました。解決策を実装したものがUDです。

  • 問題:ブログやSNSの登場とともに情報発信が簡単になった一方で、ウェブの世界には、断片的だったり、偏りのある、使えない情報が多い(通常一つのページは、とある人や組織の視点で、一つの方向性(主観)に沿って書かれることが多いため)
  • 解決策:ページが一側面を照らしているものと仮定して、別の側面が何かを併せて知ることで、はじめて、知りたいことの全体像を知ることができる(別の側面とは、例えば、異なる意見、補足的な情報、もしくは指摘などのフィードバック。)
  • 解決策の詳細:これらの情報をコンテンツに紐づく形で提供する、つまり、閲覧中のページに対して、別側面の情報(ページ作成者以外のユーザーのコメント)をする仕組みがあれば良い。

もう少し詳細に書くと、ページのURLに対して、ユーザーのコメントを紐付かせて保存し、それをウェブページの一つ上のレイヤーで位置に応じて表現する方法が良いと考えました。
それを試しに実装してみたのがモバイルブラウザのUDです。

次回以降で、このシステムをリリースするまでに行った要件定義、設計、実装の主要なトピックについて順次公開していく予定です。(続く)