銀の光と碧い空

クラウドなインフラとC#なアプリ開発の狭間にいるエンジニアの日々

connpassで先着順と抽選の両方の参加枠を用意したい

conpassでイベントを開催する際、まず何人かは先着順で参加可能にして、残りの枠を抽選にしたいということがあります。今まではこのように別々の枠に分けて募集していました。

f:id:tanaka733:20190928091537p:plain

なのですが、いくつかやりづらいなと感じている点がありました。

  • 参加者にとって抽選日直前の場合、先着順枠に入ってキャンセル待ちするか抽選枠に入って抽選に期待するか悩ましい
  • 参加者にとって抽選日以降、どちらの枠もあふれているとどちらの枠に入ってキャンセル待ちするか悩ましい
  • 運営者にとって、枠を増やせることになった場合、どちらの枠にいくつ足すか決めるのが悩ましい

いずれも「悩ましい」なので、これを悩ましく思わずえいやで決めればいいのでは?と思える人であればこのままでもいいと思います。ただ、私はこういうの時間をかけて悩んでしまう性格なので、悩まずにすむ方法はないか考えていました。

そこで思いついたのが、抽選枠は指名もできるということで、先着と抽選を同じ枠にして、運営側で先着N人を指名して当選させてしまう方法です。この方法が期待通り動作するか確認すべく、このようなイベントを作成して、Twitterで参加登録の協力をお願いしました。

connpass.com

f:id:tanaka733:20190928093407p:plain

結果としては意図通り動きました。このイベントでは先着5名が必ず当選、残り5名の枠を6番目以降に登録した人から抽選しています。5名が参加登録してくれた時点で、その先着5名を運営の機能で当選にします。登録順にIDがついているので1~5番の人を当選させました。また登録日時も分単位で確認できます。あとは放置して、connpassにより抽選を行います。

抽選により、繰り上がり順までついた状態になります。ですので、抽選日までに申し込んだ方は抽選によって決まった繰り上がり順で待つことになり、それ以降に登録した人は(抽選日前に申し込んだ人のあとで)登録順で待機列に入ります。

注意事項としては、抽選日前に必ず先着N名を当選させるように指名しないと、抽選日には先着の人も含めて抽選になってしまうということです。

参加者の決定方法は運営の人たちが決めればよいので、別にこの方法がいいよとおすすめするわけではないのですが、私としては比較的すっきりした形が実現できることがわかりました。テスト用のイベントに登録していただいた皆さんにはこの場でお礼させていただきます。ありがとうございました。

Microsoft Quantum Development Kit 0.9がリリースされていました

ブログを更新していなかった間に Microsoft Quantum Development Kit が 0.9までリリースされていました。

docs.microsoft.com

0.6については記事を書いたので、0.7から0.9までのリリースノートを簡単に日本語にしてみました。

tech.tanaka733.net

0.7 (2019/05/31 リリース)

  • Q#言語要素の追加
  • 化学ライブライの更新
  • 新しい数値ライブラリの追加

0.8 (2019/07/12 リリース)

  • 配列の部分配列を取得する場合の書き方がいくつか増えました。詳細はこちら
  • IQ# (Q#をJupyte Notebookで動かすための仕組み)を動かすDockerイメージをMicrosoft Container Registryに公開していますが、そのイメージのDockerfileの追加。
  • Trace Simulatorに関する破壊的変更。詳細はAPI Browserにて。

0.9 (2019/08/29 リリース)

なお、0.8と0.9の間で、Q#のコンパイラーやRuntimeが完全なOSSとして公開されています。

github.com

github.com

  • conjugation statementsの新しい記述方法が追加されました。
  • コンパイラーに「replace with」, 「add documentation」といった新しいコードアクションが追加されました
  • 「install template」と「new project」コマンドがVisual Studio Code拡張に追加されました
  • Jupyter Notebooksで動く、Quantum Katasのサンプルがさらに追加されました
  • Visual Studio 拡張はVisual Studio 2019を必須とするようになりました

新しく追加された文法が増えてきたので、最初のころからやっている場合は知らない要素がかなり増えてきました。改めて解説記事を書いていきたいと思います。

CloudNative Days Tokyo 2019振り返りNight に参加してきました

先日、Cloud Native Days Tokyo2019の振り返りとして行われたイベントに参加してきました。

microsoft-events.connpass.com

Cloud Native Days Tokyo2019はこのようなイベントでした。

cloudnativedays.jp

今回、Cloud Native Days Tokyoのセッションにも参加しまして、振り返りセッションにもブログ枠として参加しました。

資料はすでに公開されていますので、詳細はそちらを参照していただき、自分の感じた点を中心にまとめます。

ZOZOTOWNの描くCloud Native Journey @okahiromasa さん

ZOZOTOWNの現在のシステムはスケーラブルなモノリスで、今からマイクロサービス化を進めていくが、モノリスにもメリットはあるとおはなしがありました。新規サービスの開発に適している、性能を向上させやすい、高い運用性がある、というメリットです。特に新規サービスの開発でのマイクロサービスの難しい点として、「まだ存在していないサービスのドメイン分割は難しい。切り方を間違うことがある」というのが印象に残っています。

一方、モノリス起因の課題としていくつか挙げていましたが、「システム全体が特定技術へ依存」と「コード量増加による複雑さの増大、蓄積するDead Code / Dead Data」というのに印象に残っています。ZOZOTOWNの場合、IISとSQL Serverという技術を挙げておられました。自分もこの技術は好きですが、巨大なサービスを支えるだけの人材を揃えられるかなどは確かに懸念だろうなと感じました。

また、「コード量増大による複雑の増大」についてはマイクロサービスの方が複雑になるのではと考えたのですが、そちらの方向ではなく、使わなくなったコードやデータが残ってしまって、不必要に残ってしまうという話でした。「一時的な施策をやるためにコードを追加したけど、使わなくなった後にいざ削除するのは怖い」というのは、運用をしていた自分にとってもわかりすぎる思いです。

このような問題意識をもっていることがモノリスからマイクロサービスへの動機付けとなっているそうです。

さて、モノリスからマイクロサービスを目指すにあたり、必読とおすすめされた本があります。出版されたらぜひ読もうと思います。

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

モノリスからマイクロサービスに移行するにあたり実践しているデザインパターンとして、ストラングラーパターンが取り上げられていました。セッション中でもMicrosoft のAzureまわりのドキュメントは日本語訳がちゃんとしていると評判でしたが、そちらでも紹介されています。

ストラングラー パターン - Cloud Design Patterns | Microsoft Docs

また、クラウドネイティブの定義のおさらいとして、CNCF Cloud Native Definition v1.0を引用しつつ、クラウドプラットフォームを利用してスケーラブルなアプリケーションを作り、全体を疎結合にする。そこに自動化を加えることで、トイルが少なく頻繁な変更も怖くない日常を迎えられると説明がありました。トイルという言葉は、このイベントの前の週にあったSRE Loung #10でも頻繁に出てきた単語で、「労苦」という意味です。

sre-lounge.connpass.com

そして、「安定よりも革新に価値をもつ」という考えのもとパブリッククラウドに価値を感じているとありました。

最後に「マルチクラウド」についての話となりました。ZOZOTOWNはマルチクラウドでシステムを展開することを考えており、現在、Azure (AKS+SQL Databse)、AWS(EKS + RDS for SQL Server)に加えてGCPがPoC中とのことでした。ここで印象に残っているのが「同じ設計思想を、環境に合わせて実装する」であり、「別クラウドで全く同じ環境はあえて目指さない」ということです。「No Boundary」戦略と呼び、「インターネットにデプロイする」という表現を使っていました。

別クラウドで全く同じ環境を実現するための使えるツールもありますが、自分自身複数のクラウドを利用していて、仮想マシン一つとっても全く同じ構成を作るのは大変です。kubernetesを利用しているのであれば、アプリケーションをコンテナ化することで可搬性を担保して、複数クラウドに展開することが現実的になったのではないかなと感じました。

クラウドの特性との上手な付き合い方ZOZOTOWN篇 ZOZOテクノロジーズ杉山弘二さん

つづいて、杉山さんのセッションになります。オンプレからクラウドに移行するにあたって、オンプレにどのような課題があったか、クラウドでもどのような課題があるのかについて具体的に説明がありました。

一番印象に残っているのが、kubernetesの構築、管理コストは高いので、パブリッククラウドのマネージドサービスは非常に助かるという点、さらにkubernetesに関する質問もAzureサポートに聞くことができる、という点です。

またいくつか具体的に利用している技術要素についても説明がありました。

リトライについては、別のクラスターのみリトライを行うという戦略をとっているということです。同じクラスターは、だめになったときはしばらくダメだろうからリトライの効果が薄く、別クラスターについてはスケール変更の瞬断含めて有効だろうという考えとのことです。

SQL Databaseのコスト削減のために、Azure SQL Database Read Scale-Outの利用やオートスケールによるリソース最適化の調査結果も見せていただき、かなり具体的な話が多く楽しいセッションでした。

blogs.msdn.microsoft.com

トール・マカベッチによるアンサーソング フルコーラスバージョン@ToruMakabe

3番目に、日本マイクロソフトの真壁さんによるセッションです。

まず、Microsoftのマイクロサービスの設計パターンのドキュメントの紹介がありました。 「ちゃんと日本語訳されている」と宣伝されていましたが、Microsoftのドキュメントをよく読む私もこれ「は」ちゃんと訳されているドキュメントだと思います。先日、自分のコンテナ説明資料でも引用させていだきました。

docs.microsoft.com

次にクラウドネイティブの要素技術についてのおさらいに移ります。これは資料を読むのが一番よいと思いますが、たとえサイドカーといったkubernetesにそのものずばりが機能がある場合でも、システムとしてはkubernetesが最適解とは限らない、PaaSやServerlessのほうが都合がよいこともあるというところが印象に残っています。これはこの後のQ&Aでも話にでてきた「Serverlessを採用するのであれば、ベンダーロックインとなってもいいのでは」という判断にもつながっているのではないかと思います。

そして、ベンダー視点からのマルチクラウドの話に移ります。マルチクラウドの実現を左右するものとして、「インターフェイスとその仕様の数」があり、仕様は少ないほうがユーザーからみるとどのクラウドでも同じように使えるので使いやすいという話になります。また近年の標準化の流れとして、OSSのコミュニティで作られたものが標準化されていくというものがあり、どこのコミュニティがうまく標準化の流れを作っているのか、どこのベンダがコミュニティに参加して貢献しているのか、一つの実装が先行しすぎていないか、逆に標準化ばかり進んで実装が成熟していないか、などなど考える点が多いなと感じました。

インターフェース抽象化の流れで、Azureの中でおすすめのサービスとしてAzure Front Doorの紹介がありました。グローバル負荷分散、CDN、DDos保護、WAFも統合したうえに、バックエンドはAzureに限らずOKというものです。

azure.microsoft.com

また標準化の話では、Observabilityの標準仕様化のはなしがありました。ここは弊社New Relicもまさにターゲットとしている部分なので、弊社の立場も踏まえての話になりますが、まずOpenTracingとOpenCensusという重なる部分もあった2つのプロジェクトがOpenTelemetryという1つのプロジェクトに統合されました。

thenewstack.io

また、実装がそろっているわけではないが、各プログラミング言語ごとにexporter的にメトリクスを出力するコンポーネントが用意される予定です。Microsoftもこの標準化にのっているというお話がありましたし、New Relicとしてもこちらの標準化に注力すると発表しています。

blog.newrelic.com

ぜひ注目していただきたいプロジェクトだと思っています。そして、この標準化の先に、各サービスを差別化する一つのポイントはメトリクスデータをため、クエリを実行する時系列データベースの強さではないかというお話がありました。

Ask Us Anything! 登壇者に何でも聞いてみようのコーナー

最後にQ&Aのコーナーがありました。簡単にまとめてます。

Q: マルチクラウドDB replicationはどうやっていますか? A: オンプレからAzure,AWSへ同期している。SQL Serverの replication使ってる CDC化を探っている。、

Q: kubernetes1クラスタあたりのノード数はいくつですか? A: (真壁さんより)一般的には10ノード程度が多いと感じる。数十程度が限度で、個人的には100ノード必要なら30ノード3クラスタ用意したい。

Q: Serverless技術の採用可能性は?ベンダーロックインはOKだと思いますか? A: Serverlessならベンダーロックインしても良いと思っている。 その時に最適なものを選択するだろう

Q: GSLB はどのように実装するのがよいと考えますか? A: DNSサービス (1stクラウドサービス、2ndオンプレ)で担保しつつ、どこかのクラウドサービスを使う。

Q: AKSで動かす時とEKSで動かす時で、オブジェクトのYAMLはどの程度違いますか?(背景として、kubernetesのCloud Provierの実装により、kubernetesがプロビジョニングするクラウドのサービスの性質が各cloud providerによって多少異なっています) A: あまり違いがない程度になっている。一部、クラウドプロバイダー毎に出来上がるオブジェクトの制約から逆算して、設計している部分はある。

Q: コストマネジメントになにかサービス使っていますか? A: クラウドごとのサービスを使いたい。Azure Cost ManagementならAWSのコスト管理ができるという紹介がありました。

Q: 瞬断対応のリトライはコード実装とミドルウェア実装どちらですか? A: コードで実装しているが理想はミドルウェア。

Q:1つのクラウドの技術を追うだけでも結構大変だと思いますが、マルチクラウドの知識を社内チームに浸透させるためにどんなことをやっていますか? A: 例えば、今4人チームでそのうち3人がこの会場にいます。社内勉強会など勉強する時間をとった上で、全員がそれぞれ出来る状態にした。

CloudNative Days Kansai 2019

最後、CloudNative Days Kansai 2019が11月にあるという宣伝で、イベントは終了しました。

cloudnativedays.jp

まとめ

今回、とても面白そうなイベントだったので、Blogかくよ枠で登録し、無事参加できました。要素技術をこのように使っているとか、このように調査した、このように考えているといった具体的な話が多く、期待通り非常に面白いイベントでした。

*1:今回のイベントでも言及していただきました。