PaaS

個人で管理しているブログをAzureのPaaSに移行しました。合計で6個ほどのブログを移行してみました。 いろいろとハマってしまって、結局丸一日かかってしまったので、事の顛末を記録しておきたいと思います。 動画でも同じ内容を喋っているので、動画でご覧になりたい方は下記からご覧ください。 環境 移行元と移行先は下記です。 移行元Azure VM(Wordpress on Apache2 + MySQL)- 移行先Azure App Service(Linux)- WebApp- Azure Database for MySQL- Azure Blob Storage Wordpress on AppService Wordpress自体はAppService上でコンテナとして動作させました。このコンテナ自体は以前からこのブログ含めて複数ブログで利用していたもので、それを再利用しました。 https://github.com/ebibibi/wordpress-cocoon Wordpressの公式のイメージをもとにそこに自分が利用するテーマやプラグインを追加しているだけのシンプルなものです。 レポジトリにコードをコミットすれば自動的にGitHub Actionsでイメージがビルドされたうえで、Azure Container Registryに格納され、AppServiceにPushされるところまで全自動で動きます。 画像データのAzure Blobストレージへのオフロード 移行先の環境はコンテナなので、画像データをコンテナ内に持っておくわけにはいきません。そこでWordpressプラグインでAzure Blobストレージにあらかじめ画像を逃がすようにしました。 つかったプラグインはこちらです。 https://wordpress.org/plugins/wp-azure-offload/ 少し古いプラグインなのですが、以前から使ってますし、今回もきちんとうまく動いてくれました。このプラグインを使って、あらかじめAzureのブログに画像をオフロードさせます。その際にこのプラグインはブログのエントリーの中に埋め込まれているURLも書き換えるところまで自動的にやってくれます。 MySQL間のデータ移行 MySQL間のデータ移行に関しては、当初Azure Database Migration Servicesを使おうと考えたのですが、スキーマ移行には別途MySQL Workbenchが必要でしたし、それならMySQL Workbenchでそのままデータ移行してしまえばよさそうな感じでした。もちろんこれは私がサイトを簡単に停めても大丈夫だし、データ量も少ないからです。何度もデータ移行を継続的に繰り返さなければいけない時にはAzure Database Migration Sericesが役に立つと思います。 ですが、この方法はうまくいかず文字化けしてしまいました。原因はそもそも私が以前作っていたデータベースの文字コード設定が間違っていたからです。下記の状況でした。 Latin1に設定されたDBにUTF8のデータが入っていた- データ移行をそのまま行うと文字化け…。 いろいろ悩みましたが、結局下記の方法で回避しました。 先に移行先DBをUTF8で作成- Mysqldumpでダンプしたデータ内のcharset関連の部分を置換してから取り込み 具体的には下記のように行いました。 # c # m s s # m D r D y e e D y B e B s d d B s 作 a ダ q 取 q 成 t ン l - - り l e プ d e e 込 u み d m s s - a p / / h t l l o a - a a s b u t t t a i i = s u n n n e s 1 1 e e / _ w w r u g m p t e y _ - f n s d p 8 e q b / r l n a d a - w l b m d p _ . e e _ c m f d s y c a b / s h u n u q a l a t l r t m f . a - e 8 d c c . _ a t h d g t e a u e a r r m n b a p e a s c r s e t > a e t e l . r w _ a U - p c z T s _ i u F e d / r 8 t b e = n w . c l a p c o a m _ o l t e d m l i _ b a n u n t 1 t a - e f m u w 8 e s u p . _ e t _ d u r f d u t = 8 b m f u _ n p 8 s g a . e e m d r n e u e m - r > p p a l w > w _ p p c _ w _ i d p d ; b _ b n d n a b a m n m e a e . m d e u _ m u p t f 8 _ g e n e r a l _ c i . d u m p その他のはまった点 その他にもあれこれはまりました…。 ...

先日HCCJPにてハンズオンイベントを開催しました。ハンズオン資料作成、ハンズオン講師等務めさせてもらいました。 ざくっと概要を理解するものとしてはそんなに悪く無いできだと思いますのでよろしければ参考にしてみてください。 ※Azureの理解という観点でみると「Azure, Azure Stackで同じ概念、操作でできるもの」に引っ張られすぎている感は否定できませんけれども。 https://gitpitch.com/hccjp/hybridcloudhandson1

少し表現は異なるのですが「PaaSは勝手にアップグレードされてしまうのなら、どうやって事前にテストすればいいんでしょうか？」という趣旨の質問をたびたびされます。誰か特定の方に言われたから、というのではなく本当に多い話です。 - なにか変更を加える場合には必ず事前にテストをする - そのために本番環境とは別に本番環境を模した環境を用意している - まずテスト環境に変更を適用する、問題が見つからず全てテストが成功することが変更の絶対条件 というような運用を行なっている組織は実際のところ多いです。組織が大きくなったりシステムの重要度が上がってくるとさらに独立した環境がもう1つ、2つ増えるケースもあります。 このような組織では変更のためにかかる工数が大きく時間も必要なため、例えばWindows Serverを利用してシステムを構築しているけれども、セキュリティパッチも毎月は適用せずに数ヶ月に一度適用する…というような話もよく聞きます。 こうして、「変化」が稀にしかおきない、おこさない環境に慣れているとクラウドでは常識である「変化」に対して「知らないうちに勝手に環境に変化があるなんてどうやってテストしたらいいの？」という発想になると思います。この気持自体はよくわかります。 わたしも全てのシステムがクラウド上で変化し続けるようになるべきとはでは思っていないので、そういう「静的」なシステムおよびシステム運用があるのは良いと思うのですが、話をしているとそもそもAPIの概念を理解していないのでは?と思われる方もいらっしゃるのでその点に関してこのエントリでは書いておきたいと思います。 (ここからやっと本題です。) どのような種類の変化でもなにか破壊的なことが起こるのではないかと思って「全部テスト」という発想になる方もいらっしゃるようですが、基本的にクラウド等で発生する変化にはあるお約束があります。それは「APIは変化させない」ということです。違う言い方をすると「APIさえ変化させなければ内部では何がどう変更されても構わない」ということです。 APIという言葉はプログラマーの方でないと馴染みがあまり無いかもしれません。Application Programing Interfaceの略なのですが、まぁ、ここでは「インターフェース」としましょう。「インターフェース」が外部との連携窓口になっています。 例えばわかりやすい例として車を例にあげましょうか。車は免許があればどの車でも運転できます(大型車とかそういうのはいったんおいておきます。)。最近だと自動運転などに代表されるように、おそらく車の内部のデジタル化が進み、そうとう内部的な変化はおきていると思います。それでも、ハンドルがあり、アクセルがあり、ブレーキがあり、免許さえもっていれば車の運転はどの車でも同じようにできます。この時、人にとっての車のインターフェースはハンドルであり、アクセスであり、ブレーキです。車の世代が代わったらハンドルの形も使い方も代わってしまう…というのでは毎回免許撮り直しになってしまいますが、そういうことにはならない約束になっています。 ちょっと話を変えて、クラウド上にPaaSサービスとしてSQL Databaseがあります。例えば、Databaseに接続して、SQLクエリを実行してテーブルの中身を取得する事を考えてみます。この時、クライアントとSQL Databaseとの接続にはADO.NET、ODBC、 JDBC等のAPIが使われています。これらはクライアントとデータベース間の接続のために標準化されているものであり、いかにPaaS側が「勝手に変化」しようとも、この接続方法自体は担保しつづけます。SQLのクエリに関してもPaaS側が「勝手に変化」したとしても昨日まで通っていたSQLクエリが実行できなくなるような変化はおきません。「こんな便利な追加されました！」という変化はあっても「ADO.NETでの接続はできなくなりました！」という変化はおきないんです。というか起こさないんです。 これは、車の内部が変化したとしても、ハンドル、アクセル、ブレーキの使い方が全く変化してしまって免許を新システムで取り直さないといけないような変化は車メーカーが起こさないことと一緒です。 どんな些細な変化であってもかならずテストを事前にしなければいけないと考えるのは、どんな車のマイナーチェンジであっても、必ず事前に試乗して今までどおりに運転できることを必ず試さなければいけないと主張することに似ています。もちろんそれが現実的に運用として回せるのであれば一番安全だとは言えるでしょうけれども、場合によってはそこまでのテストをする苦労をかけるくらいであれば、万が一の時にそなえて車をもう1台用意しておくことでバックアップ手段とするようなやり方も考えられるでしょう。 PaaSの変化にもルールがあります。それでも、長い目で見ればAPIの変化も伴う変化が発生するタイミングもあるでしょう。PaaSの裏側でメジャーバージョンアップが行われるようなときです。このような影響が考えられる変化が発生するときにはクラウドのPaaSであっても事前に予告がなされますし、事前にテストをするための方策等がアナウンスされます。 どのレベルの変化の時に、どのレベルでのテストを行うのか、万が一の時のためにどのようなバックアップ手段を用意しておくのか。クラウドを使いこなそうと思ったらクラウド時代の流儀に合わせる必要があることは確かです。 例えば、仮想マシンでWebサーバーとDBサーバーがあり、アプリケーションも自分たちで書いているとします。この時に例えば、DBサーバーだけPaaSに置き換えた時に、今後PaaSのDBサーバーの自動的な変化(進化)によってエンドユーザーに影響がでる可能性というのは、わたしの考えでほぼ皆無です(※私ならWebサーバーまでPaaSに置き換えたって大丈夫でしょう、というかぜひそうしましょうよという感じではあるのですが)。でも、このレベルでも「ありえない！」という反応になってしまう方も多く、このようなエントリを書いております。なかなか難しいものです。

本日のセミナーにてMS高添さんと一緒に登壇させてもらいました。別のセッションでそれぞれ登壇…ではなくて、2人で前にたってセッションを進めさせてもらいました。ずっと高添さんと一緒にやりたかったのでやれてよかったです。 想像していたよりも私が高添さんに助けてもらうばかりになってしまいましたが、それでも楽しかったです。 さて、本日のセミナーではシステムアーキテクチャやサービス形態の変化を振り返りながら、Azure Stackがどれだけ先進的なのか、という話をさせてもらいました。 システムアーキテクチャとしては今「ハイパーコンバージド」が流行していて非常に引き合いの強さを感じているのですが、Azure Stackはハイパーコンバージドも内包しながらさらに様々なものがサービス化されています。もちろんポータルも完備されていますし、各種APIもそなえています。そしてそれはAzureとも互換性があるものです。 さらに、Azure Stackはサービスとしてのカバー範囲は仮想化の一歩先を行く「IaaS」から「PaaS」はもちろん、コンテナの管理基盤(CaaS)、サーバーレスアーキテクチャ(FaaS)もカバーします。 この図は最近書き直したのですが、以前はIaaS, PaaS, SaaSというクラウドの形態を紹介するために作成しましたが、改めて作り直してやはり今ではCaaS, PaaS, FaaSにイノベーションが多く起こっていることを実感しています。そしてオンプレミスに機器を置くAzure Stackでもこれらがカバーされる…常識を入れ替えて対応する必要を改めて強く感じています。 セミナーでも会話しましたが、このブログが動いているのは15年くらい前からずっと運用し続けているLinuxの仮想サーバーなのですが、最近新しく作った以下のサイトはCaaS, PaaS基盤を使うようにしていまして、日々の面倒なことから解放されて大変に幸せな感じです。 - [このサイトの構造について(Web App for Containers) | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e3%81%93%e3%81%ae%e3%82%b5%e3%82%a4%e3%83%88%e3%81%ae%e6%a7%8b%e9%80%a0%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6web-app-for-containers/) 自分で新しいシステムを作るならもう仮想マシンベースでは考えたくないくらいのところまで私の感覚は来ています。 クラウドを「構築する」のではなく、「使う」人の為のシステムであるAzure Stack。私が登場時に受けた衝撃はまだセミナーに来てくださっている方やお客さんに伝えきれていない気がしますが、引き続きこのような活動はしていきたいと思います。 なお、4月から会社での役職が代わりシニアエキスパートとしてより技術的な面にも時間を割けるようになる予定です。本も出したいです。それもあって新しいサイトも新しい仕組みで作ってみたりしています。このブログの更新頻度も上がる…予定です。