銀の光と碧い空

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

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:今回のイベントでも言及していただきました。

Microsoft MVPを再受賞しました

昨年に引き続き、Microsoft MVPをAzureカテゴリで受賞しました。7回目の受賞らしいです*1

昨年やったこと

昨年の4月から今年の3月までの活動実績が評価対象なのですが、こんなことをやってました。

  • Q#ハンズオンを中心とするQ#関連のブログ投稿、登壇など
  • OpenShift on Azureを中心とするAzure上のkubernetesに関するトラブルシューティングなどのブログ投稿、登壇など
  • .NET Core/ASP.NET Core をLinuxコンテナ、kubernetesで動かす場合のTips関連のブログ投稿、登壇など

次の一年に向けて

Azure関連

今年の4月に転職しまして、少し活動の方向も変わってきました。Azureから少し.NET Core/C#に戻るかもしれません。Azureに関しては、Azure上のインフラサービスやアプリケーションをNew Relicでどのように監視するかについて情報発信していきたいと思っています。昨年もやっていたkubernetes on Azureについては、kubernetes監視が監視サービスの中で重要な機能となってきているので引き続き情報発信していく機会があるかと思います。New Relic関連の情報については、このブログではなく、会社の中の人が書いていることがわかるような形で出していく予定です。

.NET Core / C# 関連

.NET Core/C#については、監視という視点での投稿が多くなるかと思います。New RelicとしてもOpenTelemetryという標準化にコミットしていくと言っているので、New Relic固有ではなく、汎用的な情報も出せるのではと思っています。また、C# TokyoというコミュニティからC#開発者向けの情報を出していきたいと思っています。興味のある方はぜひconnpassのページの下にあるリンクからSlackに参加してみてください。

csharp-tokyo.connpass.com

私からは、もっとコンテナ(論理)の良さを知って欲しいと思いハンズオンを開催していこうと思っています。第1回はすでに満員ですが、好評であれば2回目以降も開催します。もっと広い会場を貸していただけるところがあれば参加者も増やせますので、よろしくお願いします。

csharp-tokyo.connpass.com

Q#関連

Q#についてはこちらのハンズオンを継続開催していきます。

openql.connpass.com

それではまた1年よろしくお願いします。

*1:途中受賞のタイミングの変更とかあって自分ではよくわからない

AKSとQ#の試してみようリポジトリを公開しました

de:code 2019でMicrosoft MVP パーソナルスポンサーというものに選ばれまして、サンプルコードを公開していました。

www.microsoft.com

参加者向けのサンプルコードということなのですが、参加者の方にどのように伝えられたのか私は把握できておりませんので、この記事で紹介させてください。 GitHubで公開していますので、参加された方も参加されていない方も、よろしければご覧ください。ポジティブな反応が多ければ、コンテンツの方も追加してみようと思っています。

AKS

AKSは、サンプルコードというよりはサンプルコマンドと設定ファイル集と手順書のセットになっています。

github.com

コマンドと、そこで使う設定ファイル(主にkubernetesのオブジェクト定義YAMLファイル)を置いているので、手順書の通り動かせば試せると思います。 ベストプラクティスの中では、スケジュールに関連してテイントと容認を試すものや、Azure Diskをノードの限界以上に配置しようとしたときの挙動や、静的プロビジョニングの利用などが試せます。 プレビュー機能も試すことができ、dyskとblobfuseをkubernetesのstorageとして使う、Windows Server Node in AKSと、AKSではなくAKS Engineですがcosmos DBのetcd APIをkubernetesのetcdとして使う、です。

dyskとblobfuseについてはアルファ版とベータ版なのでまだまだ正式リリースまで時間がかかりそうですが、Azure Diskの場合のマウント・アンマウント処理まわりのトラブルやマウント可能なディスク数の上限が小さいといった制約を超えるために、このような動きがあるということを紹介しました。

Windows Server Node in AKSでは、Windows Server Nodeを実際に配置し、その後Windows ServerコンテナとしてWCFサーバーアプリを配置しています。また、それに接続するクライアント側は.NET Coreを使ってLinuxコンテナを使いLinux Server Nodeに配置しています。

Q#

Q#はダウンロードしたらすぐに動かせるサンプルコードです。

github.com

OpenQLコミュニティでやっているQ#ハンズオンは自分で手を動かしてコードを書いてみるというアプローチなのですが、今回のサンプルはすぐ動かせて、動いているコードを見ながらQ#を知ってもらおうという視点で用意してみました。

openql.connpass.com