銀の光と碧い空

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