ROMANCE DAWN for the new world

Microsoft Azure を中心とした技術情報を書いています。

WORKAHOLIC でワークチェアを購入した話

今年3月くらいから在宅勤務がはじまり、自宅で過ごす時間が多くなり、とくに椅子に座っている時間が大部分を占めることなります。
これまでは高級ワークチェアの購入には気が引けていましたが、これからも在宅勤務が続くことを考えると、それなりの投資をしても QOL の向上を図るほうが良さそうだと考えるようになりました。
今回は、浅草橋にある WORKAHOLIC に行って、ワークチェアを購入した話を書きたいと思います。

WORKAHOLIC とは

ワークチェアの専門店で、いろいろなメーカーのワークチェアに実際に座ってみて、座り心地を確かめてから購入できます。安い買い物ではないので、ネットの評判だけで購入するのはリスクが高いです。
現在は完全予約制となっており、電話してみると2週間待ちでした。事前準備として、自宅で使っている机の高さを測っておくようにしましょう。
www.iamworkaholic.jp

浅草橋駅から歩いてすぐのところに、店舗があります。コンクリートで隠れ家っぽいカフェ風の外観です。

f:id:TonyTonyKun:20201221191821j:plain

店内には、たくさんの種類のワークチェアが並ぶお洒落な雰囲気です。
担当のチェアコンシェルジュがついてくれて、いろいろと相談に乗ってもらいながら、ワークチェアを選ぶことができます。

f:id:TonyTonyKun:20201221191841j:plain

f:id:TonyTonyKun:20201221191900j:plain

ワークチェア選び

まずは、ワークチェアの用途を詳しくヒアリングされるので、書き仕事なのかパソコン仕事なのか、ノートパソコンかデスクトップかなどを伝えます。
次に、体に負担をかけない椅子の座り方を教えてくれ、座面やひじ掛けやヘッドレストの調整の仕方を説明してくれます。最近肩や腰のコリがひどいので、これを教えてもらっただけでも来てよかったと思いました。

f:id:TonyTonyKun:20201221191927j:plain

店内にある気になったワークチェアをひと通り座ってみましたが、座り心地がいいなと感じるワークチェアは、オカムラの Baron とかハーマンミラーのアーロンチェアで価格は15~20万でした。
だいぶ予算オーバーなので、比較的コストパフォーマンスのいいエルゴヒューマンのベーシックに決めました。

店舗で購入すると割引があるので、8万弱で購入できました。保証は5年間です。

CAFFEINEHOLIC

CAFFEINEHOLIC というカフェスタンドが併設されており、ワークチェアを購入するとチケットが貰えるので、カフェラテを飲みながら休憩して帰りました。

f:id:TonyTonyKun:20201221191946j:plain

f:id:TonyTonyKun:20201221192008j:plain

まとめ

ついに高級ワークチェアを購入するという実績を解除してしまいましたが、長時間座っていると腰や肩が痛くなるので、これで改善できることを期待しています。
あいにく店舗に在庫がなかったので、来月中旬の発送となりましたが、自宅に届くのが楽しみです。

Azure Kubernetes Service を活用したマイクロサービス開発のベストプラクティス

この記事は、Cloud Nativeアプリケーション開発のTips!日本マイクロソフト Advent Calendar 2020 の 15 日目 の記事です。
qiita.com

1年ほど前の Microsoft Ignite The Tour で、「Azure Kubernetes Service を活用したマイクロサービス開発」というタイトルでブレイクアウト セッションに登壇したのですが、現在でも通用するベストプラクティスだと思いますので、文章に起こしてみました。

gooner.hateblo.jp

Helm でマイクロサービスの構成を管理する

Helm は、Kubernetes のパッケージマネージャーです。1つのマイクロサービスは Service や Deployment など複数のリソースで構成されますが、それらの YAML をパッケージにまとめて管理できます。

このパッケージを Helm Charts と呼びます。YAML の可変部を引数として定義できるので、CI / CD パイプラインで環境に合わせたデプロイを実現できます。
Helm Charts の管理方式は、アプリケーションのリポジトリに Charts ディレクトリを含めることが多いです。
3年前の記事ですが、基本的な使い方は変わらないので参考にしてください。(以前はサービス名が ACS だったので、AKS に読み替えてください・・・)
gooner.hateblo.jp

Nginx Ingress Controller で外部向けエンドポイントを公開する

Kubernetes Cluster の外部向けエンドポイントを1つに集約し、マイクロサービスへのリクエストをルーティングすべきです。
よくあるサンプルでは、マイクロサービスごとに Service の type で LoadBalancer を設定して Public IP Address を公開していますが、これはあくまでチュートリアルです。

いくつか実現方式はあるのですが、私の経験では Nginx Ingress Controller を使うことが多いです。Nginx Ingress Controller は、Helm のリポジトリで公開されている Charts を使ってデプロイし、Ingress はマイクロサービス側で管理するようにしています。

f:id:TonyTonyKun:20201213113446p:plain

Azure ポータルから設定できる HTTP Application Routing アドオンのほうがお手軽ですが、本番運用は非推奨となっています。

アップグレード戦略には Blue / Green デプロイを採用する

マイクロサービス のアップグレード

変更頻度の高いものをマイクロサービスとして切り出すわけですから、マイクロサービス のアップグレードをどのように実現するのかは非常に重要です。
Blue / Green デプロイにより、更新中の一時的な Pod 数の減少を回避し、障害発生時に素早く切り戻せるようにしておきます。

いくつか実現方式はあるのですが、私の経験では Label Selector の Version を変更して、アクセスする Pod を切り替えることが多いです。

f:id:TonyTonyKun:20201213113616p:plain

Blue / Green デプロイのためだけにサービスメッシュ(Istioなど) を導入するには、コストが高く、複雑になりすぎると考えています。

Kubernetes Cluster のアップグレード

意外と考慮事項から漏れてしまうのが、Kubernetes Cluster のアップグレードです。Kubernetes の更新サイクルの速さにどのように追随していくのか、しっかりと検討しておくべきです。
AKS には Kubernetes Cluster をインプレースでアップグレードする方法が提供されていますが、本番運用ではリスクが大きいので採用したくありません。
Blue / Green デプロイにより、動作確認済みの Kubernetes Cluster を Production として利用し、障害発生時に素早く切り戻せるようにします。

f:id:TonyTonyKun:20201213113716p:plain

この方式をシンプルに実現するため、あえて AKS の構成に制約を持たせています。

  • Kubernetes Cluster 内ではデータを永続化せず、外部のストレージを利用する
  • Application Gateway V2 を配置し、Kubernetes Cluster のフロントでエンドポイントを切り替える

この制約を持たせることで得られるメリットの方が圧倒的に大きいという判断です。

Pod と Node のスケーリングを組み合わせて構成する

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler は、Metrics Server を利用した Pod のオートスケーリングです。Pod の CPU 利用率を閾値として、Pod 数を最大最小の範囲内で自動的に増減できます。

$ kubectl autoscale deployment <DeploymentName> --cpu-percent=50 --min=1 --max=3

Deployment の YAML で、Resources の requests と limits の設定していることが前提となります。

resources:
   limits:
    cpu: 200m
    memory: 256Mi
   requests:
    cpu: 100m
    memory: 128Mi

Cluster Autoscaler

Cluster Autoscaler は、高速なスケーリングを可能にするため、仮想マシンスケールセット(VMSS)を利用しています。

  • Status が「Pending」の Pod があると、Node を上限数まで増やしてくれる
  • Pod の Requests 合計が 50% を下回る Node を削除候補に、下限数まで減らしてくれる
$ az aks create \
    --resource-group <ResourceGroupName> \
    --name <AKSClusterName> \
    --node-count 1 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler \
    --min-count 1 \
    --max-count 3

導入時は Cluster Autoscaler を使わずに、Node 数を固定して運用を開始する方法もありだと思います。

障害が発生する前提で構成を決める

Master Node

Master Node は、マネージドサービスとして隠蔽されているため、Azure 側に管理を任せます。AKS としてマネージドサービスで利用する大きなメリットの1つです。

Node

障害によって非アクティブと判断された Node に配置されている Pod は、別の Node に再デプロイされるため、余裕を持たせた Node 数で運用する必要があります。

仮想マシンスケールセット(VMSS)の可用性セットによって、Node の仮想マシンは異なるラックに配置されています。Availability Zone を利用すると、1リージョン内で物理的に分離して Node の仮想マシンを配置することができます。

AKS Cluster はリージョンをまたげないので、大規模な DR を構成する場合には、複数の AKS と他のサービスを組み合わせた対応が必要となります。

  • Azure Traffic Manager
  • Azure Cosmos DB

Pod

Pod については、Deployment の YAML で下記の3つの項目を設定しておきます。

リソース 説明
Replica Set 指定した Pod 数に満たない場合、自動的に新しい Pod を作成します。
Liveness Probe Pod(Container)の死活監視です。応答が返ってこない場合、自動的に Pod が再起動されます。
Readiness Probe Pod(Container)がリクエストを受け付けられる状態の監視です。エラーを返す場合、Kubernetes がリクエストを送信しません。バックエンドのデータストアをチェックする API などを作ります。
livenessProbe:
 httpGet:
  path: /
  port: 80
readinessProbe:
 httpGet:
  path: /readiness
  port: 80

Azure Monitor でマイクロサービスを監視する

マイクロサービス全体で何が起きているのかを把握するため、Azure Monitor for Containers と Application Insights を使ってメトリクスとログを収集します。AKS としてマネージドサービスで利用する大きなメリットの1つです。

f:id:TonyTonyKun:20201213113820p:plain

Azure Monitor for Containers

Kubernetes Cluster の Node や Pod から、メトリクス(Memory / CPU)とログ(stdout / stderr)を収集し、Log Analytics へ送信します。KQL(Kusto Query Language)のクエリで抽出できるので、必要に応じてアラート通知を設定します。

f:id:TonyTonyKun:20201213113915p:plain

Application Insights

アプリケーションにライブラリを追加し、テレメトリデータを送信します。分散トレーシングにより、マイクロサービス におけるパフォーマンスのボトルネックやエラーの根本原因を追跡できます。

f:id:TonyTonyKun:20201213114032p:plain

まとめ

Azure Kubernetes Service を活用したマイクロサービス開発のベストプラクティスを紹介しました。
マイクロサービスを実現する手段は、Kubernetes だけではありません。本当に Kubernetes が必要かどうかを十分に検討しましょう。

  • リリース後、サービスが頻繁にアップデートされますか?
  • 新しいサービスが頻繁に追加され、サービスの数が増えていきますか?

Kubernetes を採用するなら、シンプルな構成から始めることを推奨します。すべての機能を使わず、必要な機能を選択して利用しましょう。あえて制約を課すことで、シンプルさを優先する選択もあります。

Azure Synapse Analytics を試してみた

この記事は、NEXTSCAPE Advent Calendar 2020 の 1 日目 の記事です。
qiita.com

Azure には以前から SQL Data Warehouse(SQL DW)というサービスがありましたが、Synapse Analytics (formerly SQL DW) に名称変更されました。
これとは別に SQL DW が統合された Data Platform のサービスとして、Synapse Analytics (workspaces preview) というサービスが登場しました。
今回は、こちらの Synapse Analytics (workspaces preview) を試してみました。

Synapse Analytics

ひと言でいえば、Azure で Data Platform を作るときに必要となる複数のサービスをまとめて管理できるサービスです。
公式ドキュメントでもいいのですが、Microsoft MVP の方が作ったこちらの資料が分かりやすいです。

www.slideshare.net

従来は、Data Factory / Data Warehouse / Databricks などを組み合わせて、Cold Path と Hot Path の2つのパスを作成するラムダアーキテクチャの構成を組んでいました。

f:id:TonyTonyKun:20201128095338p:plain

Synapse Analytics では、これらのサービス群が統合された1つのサービスとして提供されています。

f:id:TonyTonyKun:20201128095352p:plain

統合サービスなので提供される機能の範囲が広いため、まずはデータ分析エンジンの SQL pools と Apache Spark pools を中心にさわっていきたいと思います。

事前準備

Data Platform 系のサービスを試すときに面倒なのが、サンプルデータの作成です。公式ドキュメントでは Microsoft が提供しているオープンデータを使っています。
もう少しお手軽にデータを作りたいときには、mockaroo というサイトがお勧めです。

f:id:TonyTonyKun:20201128112510p:plain

無料でも 1000 件までなら、CSV や JSON のランダムなデータを作成できるので、クエリ検証作業が捗ります。

Synapse Analytics を作成する

Azure Portal で Synapse Analytics (workspaces preview) を作成します。先週ぐらいから、東日本と西日本も使えるようになりました。
Data Lake Storage の BLOB データ共同作成者ロールを自分に割り当てるかどうかのチェックボックスは、忘れずに ON にしておきましょう。その他の項目は、公式ドキュメントを参照してください。
docs.microsoft.com
リソースが作成されると、Azure Portal とは別のツールである Synapse Studio を起動できます。Synapse Analytics を使うメリットの1つで、データのインジェスト→分析→可視化のための開発やモニタリングを行うことができます。

f:id:TonyTonyKun:20201128114043p:plain

SQL pools

SQL を使った分析エンジンで、Serverless と Dedicated の2つのタイプがあります。どちらのタイプも、SSMS や Azure Data Studio などのツールで接続できます。

f:id:TonyTonyKun:20201128120827p:plain

Serverless SQL pools

Azure Data Lake Storage(ADLS)においたファイルに対して、SQL を実行できます。対応しているファイルの形式は、CSV / JSON / Parquet の3つです。
mockaroo で作成した CSV ファイルを ADLS の demo コンテナーにアップロードし、Synapse Studio から SQL script でクエリを実行してみます。

f:id:TonyTonyKun:20201128160034p:plain

OPENROWSET 関数を使ってデータ ソース (ファイルなど) の内容を読み取って行のセットとして返すことができます。WITH 句を使ってスキーマを指定しなくても、ファイルからスキーマを自動検出してくれます。

SELECT TOP 100 *
FROM OPENROWSET(
      BULK 'https://gooner1201lake.blob.core.windows.net/demo/*.csv'
    , FORMAT = 'CSV'
    , PARSER_VERSION = '2.0'
    , HEADER_ROW = TRUE
)
AS results
ORDER BY First_name ASC

推論されたデータ型を確認したい場合は、こちらのクエリを実行します。

EXEC sp_describe_first_result_set N'
SELECT TOP 100 *
FROM OPENROWSET(
      BULK ''https://gooner1201lake.blob.core.windows.net/demo/*.csv''
    , FORMAT = ''CSV''
    , PARSER_VERSION = ''2.0''
    , HEADER_ROW = TRUE
)
AS results
ORDER BY First_name ASC';

Serverless SQL pools の master データベースは、照合順序に SQL_Latin1_General_CP1_CI_AS が使われているため、日本語が文字化けします。
そのため、日本語を使える照合順序を指定したデーターベースを作成し、このデーターベースを選択してクエリを実行することで解決できます。

-- データベース作成時に照合順序を指定
CREATE DATABASE mydb COLLATE LATIN1_GENERAL_100_CI_AS_SC_UTF8

techcommunity.microsoft.com

Dedicated SQL pools

従来からの SQL DW と同様のサービスなので、ここでは詳しくは説明しません。
Synapse Studio の Manage メニューから、Dedicated SQL pools のデータベースを作成できます。

f:id:TonyTonyKun:20201128115539p:plain

他のサービスに比べて価格が高いので、簡単な検証であれば DW100c を選択しておきましょう。さらに、使わないときはデータベースを停止しておくことで、課金を節約できます。

Apache Spark pools

Spark を使った分析エンジンで、タイプは Serverless のみです。データをメモリに読み込んでキャッシュし、並列にクエリできるのでパフォーマンスに優れています。
Synapse Studio の Manage メニューから、Apache Spark pools を作成できます。

f:id:TonyTonyKun:20201128115342p:plain

Spark pools には、デフォルトで Spark Core や Anaconda などのコンポーネントが含まれていますが、必要なライブラリを追加構成することもできます。
簡単な検証であれば、Small サイズの Node を最大3つぐらいで十分だと思います。

Synapse Studio から Notebook でコードを実行してみます。PySpark (Python) 以外の言語には、Spark (Scala) / SparkSQL / .NET for Apache Spark (C#) を使うことができます。

f:id:TonyTonyKun:20201128173353p:plain

DataFrame を作って CSV と Parquet のファイルにエクスポートしてみます。

# DataFrame の作成
new_rows = [('CA',22, 45000),("WA",35,65000) ,("WA",50,85000)]
demo_df = spark.createDataFrame(new_rows, ['state', 'age', 'salary'])
demo_df.show()

# CSV にエクスポート( users/user/trusted-service-user/demo_df/ に作成される )
demo_df.write.csv('demo_df', mode='overwrite')

# Parquet にエクスポート
demo_df.write.parquet('abfss://users@gooner1201lake.dfs.core.windows.net/demodata/demo_df', mode='overwrite')

データのインポートとエクスポート

Synapse Studio の Notebook から ADLS / SQL pools / Spark pools に対して、データのインポートとエクスポートを試してみます。
各データストアへの認証には Managed Service Identity(MSI)が使われており、認証周りを意識せずにコードを書けるのは Synapse Analytics を使うメリットの1つだと思います。

ADLS の CSV を Dedicated SQL pools のテーブルにコピーする

ADLS の CSV を DataFrame に読み込みます。

account_name = "gooner1201lake"
container_name = "demo"
relative_path = "*.csv"
adls_path = 'abfss://%s@%s.dfs.core.windows.net/%s' % (container_name, account_name, relative_path)

df = spark.read.option('header', 'true').csv(adls_path)
df.show(10)

Dedicated SQL pools への転送には scala を使います。異なる言語間で DataFrame を共有できないため、Spark の一時テーブルを経由させます。

df.createOrReplaceTempView("pysparktemptable")

scala への言語の切り替えには、マジックコマンド(%%spark)を使います。Dedicated SQL pools の PolyBase によってデータが転送されます。

%%spark
val df2 = spark.sqlContext.sql ("select * from pysparktemptable")
df2.write.sqlanalytics("SQLDW1.dbo.Person", Constants.INTERNAL)

Dedicated SQL pools のテーブルを Spark テーブルにコピーする

%%spark
val df = spark.read.sqlanalytics("SQLDW1.dbo.Person") 
df.write.mode("overwrite").saveAsTable("default.t1")

Spark テーブルを Dedicated SQL pools のテーブルにコピーする

Spark テーブルを DataFrame に読み込み、Spark の一時テーブルに転送します。

df = spark.sql("SELECT * FROM default.t1")
df.createOrReplaceTempView("pysparktemptable")

Dedicated SQL pools の PolyBase を使って、別テーブルにデータを転送します。

%%spark
val df2 = spark.sqlContext.sql ("select * from pysparktemptable")
df2.write.sqlanalytics("SQLDW1.dbo.Person2", Constants.INTERNAL)

まとめ

Synapse Analytics について、データ分析エンジンの SQL pools と Apache Spark pools を中心に試してみました。
Synapse Studio を使うことで、データのインジェスト→分析→可視化のための開発やモニタリングを1つで管理でき、各データストアへの認証周りを意識せずにコードを書けるのは便利だと感じました。

次回は、データ分析エンジンの実用的な使い方やパイプライン周りの機能も試していきたいと思います。
gooner.hateblo.jp