Movatterモバイル変換

[0]ホーム
URL:

Hirosaji Tech Blog 🍙

Web開発の記事が多め。絵師支援の記事も少し。

Green環境構築が終わらないRDS Blue/Green Deploymentsの原因と対応策

RDS の Blue/Green Deployments（以下、B/G Deploy）が re:Invent 2022 で発表されて約３ヶ月が経ちました。
ちょうど機会があったため業務で利用してみたところ、B/G Deploy には思わぬ落とし穴がいくつかありました。

この記事では過去に報告されている事例も含めて、私が今回ハマった落とし穴とその解決法をまとめました。

何が起きたか：Green環境の構築が終わらない

🍙「コンソール操作で B/G Deploy を実行した！」
🍙「エラーも出ないし、少し待てば Green 環境が構築されるはず」
（５時間経過...）
🍙「ステータスを見ても、一向に進捗がない...」
🍙「Green 環境の構築が！いつまでも！終わらない！！」

数時間ずっとこの画面のまま

エラーも表示されないので問題の原因がかなり難しく、🍙は途方に暮れてしまいました。

原因①: エンジンバージョンが非推奨(deprecated)になった

B/G Deploy を実行した RDS cluster のエンジンバージョンが、AWS上で"非推奨"とされたときにこの問題は起こります。

非推奨だとclusterの設定変更でこんな警告が出る

非推奨のエンジンバージョンは基本、古いバージョンです。
非推奨のバージョンは、次のドキュメントにまとめられています。

しかしゼロデイ対応など何らかの緊急対策で、ドキュメントの更新無しに突然使っていたエンジンバージョンが"非推奨"とされてしまうことがあります。
そして非推奨のエンジンバージョンの cluster / instance は、いくつかの設定の変更（インスタンスクラスの変更など）がロックされてしまいます。
これが B/G Deploy が実行できない原因にもなるようです。これを回避するには、推奨バージョンへのアップグレードが必要です。

緊急の即時対応ということもあってか、例外処理やエラーメッセージも用意されていないので、この原因特定にはかなり苦労しました。
（私はこの落とし穴にハマって、原因特定に１日溶かしました...）

追記: 2023/03/08

AWSのSAに聞いたところ、2023年4月3日に AuroraMySQL 2.09 と 2.10 系バージョンが廃止されることになったとのことでした。
それに伴って、廃止されるバージョンで新しいクラスターが作成できなくなったとのこと。

確か B/G Deploy は内的に、同じエンジンバージョンの新規クラスターを作成 →マイグレーション → エンジンバージョンアップ... という手順を踏んでるので、この手順の"新規クラスター作成"がロックされたことが B/G Deploy が使えない原因のようですね。

なお、4月3日以降は定期メンテナンスで自動的に 2.11 へアップグレードされる予定みたいなので、急ぎの用事がなければそのままでも良さそうです。
詳しくは、管理者宛に[Action Required] Upgrade Aurora MySQL to Aurora MySql 2.11.1 or Higher というタイトルの案内メールが届いてるそうなので要チェック。

原因②: clusterのサブネットグループが3AZ未満

一般に本番環境で稼働させるRDSの基本構成には、サブネットグループに３つの異なるAZを含めます。
この基本構成は、公式のチュートリアルでも案内されています。

DBクラスターで選択する DB サブネットグループは、少なくとも ３つのアベイラビリティーゾーンを対象とする必要があります。

マルチ AZ DB クラスターの作成 - Amazon Relational Database Service

これは高い可用性を前提とするRDSにおいて、（実際には配置しなくても）RDSインスタンスが配置されうるサブネットを事前に用意しておく必要があるためです。

そして RDS B/G Deploy では、このサブネットグループの用意＋アタッチが必須になっているようです。

原因③: Green環境でアップグレードしたエンジンバージョンにインスタンスクラスが対応してない

例えば、Aurora3 (MySQL 8.0) は t3.small に対応していません。（対応表はこちら）

この問題に対応するにはインスタンスクラスを変更する必要がありますが、当然価格も変わるので、請求時に泣きを見ないよう事前に変更後の料金を確認しておくと良いと思います。（料金表はこちら）

その他の落とし穴

AWS公式から、次の機能が含まれる cluster はサポートしていないとのアナウンスがされています。

Aurora 用 Amazon RDS ブルー/グリーンデプロイの概要 - Amazon Aurora

他にも、

  • binlog を出力するパラメーター（binlog_format）の有効化
  • binlog_format の適応（インスタンスの再起動が必要）
  • Blue側での事前の binlog 生成

が必要とのことで、これらについては先人の方々がまとめてくれています。

  1. Amazon RDSのBlue/Green Deploymentsを実験して気づいたハマりポイントまとめ
  2. Amazon RDS Blue/Green Deployments利用時に躓いたエラーやハマりポイントなどをまとめてみた - コネヒト開発者ブログ
  3. AuroraMySQLのバージョンアップをBlue/Greenデプロイを利用して実施してみた | GROUP DEV BLOG | TECHNO DIGITAL

RDS B/G Deploy はまだリリースしたばかりの先駆的な機能なので、これを読んだ方ももし何かを発見したら、情報発信してくれたら嬉しいです。

【メタサーベイ】イラストの心理戦略をこれからサーベイする人のために

先日、イラストの心理戦略を紐解くアプローチをPyCon JP 2022にて発表しました。

イラストは、さまざまな分野の知識体系や経験則が凝縮してできた文化で、その多くを把握するのはとても大変です。
しかしイラストを観る人でも描く人でも、イラストに込められた知識や経験を知っているほうが、よりイラストを楽しむことができます。

そこで今回はイラストの心理戦略にスポットを当て、重要な知識や経験を改めて体系化しました。

そのために取り組んだのがイラストの心理戦略の"メタサーベイ"です。
これからイラストを"サーベイ"する人の足がかりとなる記事を目指しました。

諸注意

  1. 科学 ＜ 経験則がベース（私の知識はイラストの技法書がベースなので、たぶん厳密性に少し欠けます。疑って読むくらいがちょうど良いです！）
  2. エンジニア用語がﾁｮｯﾄあります（エンジニア向けに書き始めた記事なので、エンジニア用語を少し解説に挟んでます。わからなかったら読み飛ばしてOK！）

用語説明

サーベイとは

サーベイとは調査を意味する言葉で、特に”物事の全体像や実態を把握するための調査"のことを指します。

これに関連するのが「リサーチ」で、これも調査を意味する言葉です。
リサーチは、"目的や対象が明確で、より細かな事実を把握するための調査"を指します。
それに対してサーベイは、"目的や対象をはっきりさせるための調査"という位置付けです。

そして、このサーベイに「メタ（高次の）」という語句を付け加えたのが「メタサーベイ」です。

メタサーベイとは

メタサーベイという言葉にはまだ明確な定義はありませんが、関連して有名な言葉に「メタ認知」があります。

メタ認知とは、"自分の認知活動（思考や行動）そのものを客観的にとらえて整理すること"。つまり、自らの認知を認知することを指します。
するとメタサーベイは、"自分のサーベイそのものを客観的にとらえて整理すること"。つまり、自らの調査を調査することだ、と言えるでしょうか。

特に最近の学術界隈では、後続のためのサーベイ支援という意味合いが強いようです。
次に続く人が参入しやすい形に要点を整理して、学習リソースを紹介するところまでがメタサーベイの一連の流れとされています。
（日本ではcvpaper.challenge の活動がその代表例ですね）

私もこの学術界隈の慣習にならって、メタサーベイをしてみました。

「イラストの心理戦略」のメタサーベイ

PyCon JP 2022での私の発表でも、イラストの心理戦略を体系化して解説しました。

発表では、イラストを構成要素に分解し、中でも心理に作用しやすい色／光／キャラクターの３要素について解説しました。
しかし一般的なサーベイにあたって、この３要素を使うことは必ずしも重要ではありません。
なぜなら発表の例はあくまでも、プログラムでの検出を前提として、調査対象を限定したアプローチだったからです。

そこでこの記事では、改めてより汎用的にサーベイしやすい分類を策定しました。

  • イラストに描くモノのことを考え、モノの構造を知る
  • イラストを観る人のことを考え、ヒトの心理を知る
  • イラストを評価する社会のことを考え、社会の仕組みを知る

この３つに対して、学問領域などのトピックを分類したのが上図です。
続いて、この３つの背景や動向、学習リソースをそれぞれ紹介します。

「モノの構造」を知る

『え、モノの構造を知ることが、心理戦略につながるの？』という疑問を抱く人もいるかもしれませんが、非常に重要です。

なぜなら人間は、知っているけど何かがおかしい、つまり歪んだ既知のモノを嫌うからです。

人間の視覚は、中心窩（視野の中心2度の領域）を除く周辺視野の情報の多くを推測で補完しています。
歪んだ既知のモノは、周辺視野での推測の精度が悪く、あまり推測の精度が悪いとヒトは「異常なモノが目の前にある」と強く認識してしまいます。
（それが未知のモノであれば、新しく覚えることで推測の精度が上がる）

これを、ヒトの情報処理システムを例に説明してみます。

感覚器官を使ったヒトの情報処理システムの構造は、多階層のマイクロサービスです。

感覚→知覚→認知...というフローの処理を逐次実行しながら、注意／選択／抑制／制御という割り込み処理を管理する、という情報処理を私たちは日夜こなしています。
（脳の機能をモジュールと見なすアプローチは全脳アーキテクチャより）

では低品質な、雑に言うと下手なイラストを見たとき、ヒトの情報処理はどうなるでしょう。

例えば、物体認識や異常検知の関数でエラーやアラートが鳴ります。
これによって、注意／選択／抑制／制御の割り込み処理が発生します。

ヒトの情報処理は逐次実行されているため、エラーやアラートが鳴り続け、割り込み処理が発生し続ける状態になります。
やがてヒトはアラート疲れを感じ、そのイラストへの関心を失ってしまいます。

この説明は超ざっくり版なので、もしヒトの情報処理システムをより厳密に知りたい方は、各自調べてみてください。
個人的には、次の解説論文がおすすめです。

以上、イラストの戦略のために、なぜモノの構造を知る必要があるのかをまとめました。
結局何が言いたかったかというと、モノを"正しく"描くことは、ヒトの心を動かす上での大前提であるということです。

ただ、写実的に描くことが"正しく"描くこと、というわけではありません。
モノを特徴づける特徴を、より特徴づけるカタチに描くことで、ヒトは"正しさ"を感じやすくなります。

以下では、それらの学びに役立つ重要な歴史やおすすめの書籍、フォローを推薦する方々をまとめました。

「ヒトの心理」を知る

ヒトの心理を知ることも、もちろんイラストの心理戦略に役立ちます。
これに関しては言うまでもないですね。

特に目の前のモノからどんな特徴を抽出し、どのように処理するか、といったヒトの認知プロセスに関しては既に多くの知見があります。
（「モノの構造」を知る、の説明でも少し触れました）

知見が多い分、基礎も幅広いので、ここではとても解説しきれません。
いくつかの大学が知見をまとめた資料を公開しているので、しっかり勉強したい方はまずそれらを調べてみるといいと思います。

また最近は、進化心理学という領域が一部で注目を集めています。
既存の前提（社会学や生物学など）を覆すアプローチがいくつも提唱されていて、しばらくはHotなトピックとなることでしょう。

以下、おすすめの書籍やフォローを推薦する方々をまとめました。

「社会の仕組み」を知る

社会の仕組みを知ることも、イラストの心理戦略に役立ちます。
特にイラストレーターが、自身の創作活動を長期的に続けるために必要です。

イラストレーターは自身の特性を鑑みて、日頃どう振る舞うべきかを常に考えています。
リスクを予測しつつ、自身とファンの満足度を最大化させることが、イラストレーターの本懐です。
（ただし、企業に所属するイラストレーターは少し振る舞いが異なる）

そのためには、ファンの心理や世間の情勢を観測し続けることが大事です。

そして、特に有効なのが、イラストレーター自身が目指したいロールモデルとなるプロ絵師を見つけること。
エンジニアが自分のプロダクトに合ったベストプラクティスを参考にするように、イラストレーターも自分の創作活動に合ったロールモデルを参考にするのが近道です。

ちなみに、私が理想とするロールモデルはGUWEIZ 氏。
彼の自己学習（独学ではない）の精神や、ファンとの対等な関係性は、私にとってトレースしたいと思うほどの理想形でした。
（詳しくはThe Art of GUWEIZ グウェイズ画集 で語られてます）

さらに、ロールモデルの振る舞い一つ一つの効果を分析／予測できるようになるのがベターです。
以下、おすすめの書籍とフォローを推薦する方々をまとめました。

その他

プロのイラストレーターの中にも、自身の思考を可視化して伝える取り組みをされている方が何人かいます。
中でも、次の４名はフォロー超オススメの方々です。

ストーリーを感じさせるイラストを描くには、動機→行動→結果の時系列を意識するといい話pic.twitter.com/pK0XvNhhga

— フジワラヨシト|ｲﾗｽﾄﾚｰﾀｰ (@fuji25_2501)2022年8月25日

デッサン力とか関係なく、これさえ覚えれば嫌でもTVアニメ風になるやつpic.twitter.com/bl2uX3nBz9

— かおりゅ (@caoryu_YS)2021年5月11日

絵の作業工程を、日記の感覚でまとめました。
暇すぎる人向け。pic.twitter.com/q88IxOuaRl

— 池上幸輝Koki Ikegami (@winter_parasol)2022年10月12日

解説付きのメイキングもあるのでよかったら見て〜🌱

🎨今週の動画🎨
▶【イラストメイキング】構図を決める時に考えていること【ウマ娘:マヤノトップガン】046https://t.co/HNujHXB5OMpic.twitter.com/GzF5lgf2Km

— 絵葉ましろ🎨🌱お絵描きVtuber (@eva_mashiro)2022年3月24日

この４名も含め、イラストを理解するために必要な暗黙の知識やニュースを発信している方を（知っている限りまとめて）次のリストに追加しました。
良ければフォローをどうぞ。

イラストを学問とする講座を持たれている方をフォローするのもオススメですね。京都芸大（KUA）やColosoの講師陣とか。

もし他にもオススメな方がいたら、この投稿へのコメントなりTwitterなりで教えてもらえると、とてもとても嬉しいです。とてもとても。

終わりに

この記事では、「イラストの心理戦略」のメタサーベイに挑戦しました。

メタサーベイでは、心理戦略をサーベイする枠組みを改めて再定義し、基本方針や学習リソースを紹介しました。
心理に関連する研究は歴史が長く、日本語でまとまった資料も多いので、カバーすべき量は多いもののサーベイに困ることはないかと思います。

ただ、ちょっと反省として、カバーする範囲を広くしすぎて基礎的な内容までしか踏み込めなかったことが悔やまれます...。
今回が私にとって初めてのメタサーベイだったので、この学びは次回に活かしたいですね。

今後も、イラストをもっと楽しむための情報発信（ニュースや暗黙の知識など）をしていくので、興味ある方はTwitterをフォローしてみてください。twitter.com

PyCon JP 2022 で「続・絵を読む技術 Pythonで読むイラストの心理戦略」を発表しました

３年振りに現地開催されたPyCon JP 2022に、個人名義（Hirosaji／ひろさじ）で登壇しました。

今回でPyCon JPへの登壇は３回目。
発表内容は去年の続編という位置付けでしたが、Stable DiffusionをはじめとするAI絵師への関心もあって、想像以上に多くの方に楽しんでいただけました。

この記事では、そんな発表の概要や会場での質疑応答などをまとめました。
また、長くなったので別の記事に分けましたが、発表内容のメタサーベイにも挑戦しています。

発表を見た方でも見ていない方でも楽しめる内容です。よろしくどうぞ。

イベント概要

  • 概要：日本最大級のPythonユーザカンファレンス
  • 日時：2022年10月14日（金）～ 2022年10月16日（日）
  • 会場：TOC有明コンベンションホール
  • 公式 HP：https://2022.pycon.jp/

登壇内容

発表内容


続・絵を読む技術 Pythonで読むイラストの心理戦略（Hirosaji / ひろさじ, 30min）

一言で言うと、イラストレーターがイラストに込める戦略をイラストの技法書をベースに体系化し、その戦略をPythonを交えながら解説しました。
今回の発表はその第２弾（第１弾はこちら）という位置付けで、イラストの心理戦略にスポットを当てました。

イラストの心理戦略は、イラストの構成要素のうち心理に作用しやすい色／光／キャラクターの３要素を取り上げました。
特に重点的に解説したのは、キャラクターの魅力を引き出す定石と、配色によるコンセプト設計についてです。

また、解説の合間に紹介したPythonスクリプトの趣旨と要素技術は次の通りです。

  • 3D姿勢推定モデル（SMPL）+ MeTRAbs でコントラポストを検出
  • NudeNet モデルで露骨な表現を検出
  • DeepWB + mixedillWB で自動ホワイトバランス
  • matplotlib による可視化で配色コンセプトを分析
  • CarveKit で被写体と背景を分離
  • エントロピー計算で描き込みの多い領域を推定

詳しくは、スライド資料または動画アーカイブをご覧ください。

会場で受けた質問と回答

  • 人外系絵師はAIの学習量が少ない。一般的な人を描く絵師に競争負けするのでは？
    （しばらくは）その通りだと思う。人外系に限らず、学習が少ないニッチ層の人たちは大変だろう。一応対策として、例えば人の生成が得意なNovelAIからは"構図"のみを参考にする、などイラスト全般のアイデアの一部を抽出することはできる。
    また、NovelAIにこだわらなければ、人外系でも結構生成できるようだ。

    AI君の事、美少女画像生成器くらいにしか思って無い人結構居そうだなって#WaifuDiffusion#StableDiffusionpic.twitter.com/C6HSmayfUz

    — ビームマンＰ ver4.1 (@BeamManP)2022年10月16日
    人外系はニッチとはいえ、市場に一定以上の需要があるため、これらの他にも人外特化モデルが今後できることには期待している。

  • AIもコントラポストなどの定石に沿った絵を出力する？
    学習時の入力に寄るが（いま人気のNovelAIやWaifu Diffusionは）その通りだろう。
    世に出回るキャラクターイラストは、多くがコントラポストや性戦略などの定石に沿っているので、その定石を出力しがち。

  • JOJO立ちはコントラポストという理解で合ってる？
    ほぼ正解。調べたら代表的なJOJO立ちの多くがコントラポストに沿っていた。
    逞しい男たちに女性が得意なコントラポストを取り入れると、迫力と美しさが同時に表現できる、という発見をした荒木先生はすごい。

  • 実際に絵を使うときに、カラー分布を使う作業はする？時間短縮につながる？
    時と場合、イラストレーターのスタイルによる。例えば、ビジュアルリファレンスから直接カラーパレットを作る場合は、カラー分布は最終確認くらいにしか使わない。
    しかし、事前に配色が決まっていない場合は、カラー分布を随時参照することで、全体を俯瞰しながら配色を決めることができる。人間はシングルタスクしかできないため、色を塗る作業（に限らないが）は、どうしても塗っている周辺の局所的な彩色バランスに集中してしまいがち。すると、全体の配色バランスの再調整がよく必要になり、タイムロスが起こる。そのため、随時カラー分布で俯瞰しながら全体の配色バランスを考えるのは時間短縮につながりやすく、最終的なイラストの品質を高く保つ効果が期待できる。

  • 普段どんなツール（ソフトウェア）で描いている？
    iPad Proか液タブにて、CLIP STUDIO PAINTとPhotoshopを使って描いている。
    CLIP STUDIO PAINTは日本語の学習資料が多く、Photoshopは万能ツールである点で、それぞれ国内市場の覇権を握っている。ただ、最近はProcreateも気になっている。（お絵描きにPythonは使ってない）

  • 記憶色か自然色かを分析する手法はあるか？
    分類や精度の高い回帰分析などは難しい。特に分析対象をイラストとするととても難しい。イラストに現れる記憶色は、イラストレーターの脳内の記憶色が使われる他、一部にだけ記憶色を使うというデフォルメ手法もあり、なお分析が難しい。
    また、記憶色に一貫した傾向があるかを調べた研究もある。記憶色は、実際の色よりも彩度や明度が高くなりがちだが、色やモノによってその振れ幅が異なる（Memory Colors of Familiar Objectsより）。さらに、時間が経つにつれて、記憶色は変化していく（色記憶の再生による色の三属性の移行についてより）。
    以上より、人やモノによって記憶色の解釈は異なるため、定量分析はまず難しいと考えている。

  • AIの画像を見て「これは使えるな」と思ったことは？また実際に使ったことは？
    直近では、発表の最後に紹介した絵柄学習AIに可能性を感じた。インスピレーションの元にしたり、描いたことのないオブジェクトを自分のスタイルでどう描けばいいかの参考になる。
    他にも、色ラフからシーンに合ったカラーパレットを作る事例も。

    Novel AIイラストを参考画像として使えないか試してみました！
    今回やったのはざっくり色ラフを描き、それを元に出力したものを参考に色ラフを詰めていくというものです。
    結果、今回たまたまかもしれませんが想像以上にうまくいきましたので、やったことをそのまままとめてみました！pic.twitter.com/TW163S5JlZ

    — ワンダルチア (@Wander00317)2022年10月11日
    このような実用事例をまだ私は持ち合わせていないので、これから模索する。

発表後の反響

Twitterにて、発表資料を載せたツイートに多くの反応（いいね／RT）をいただきました。

本日の発表資料です。#pyconjp#pyconjp_4
「続・絵を読む技術Pythonで読むイラストの心理戦略」を、PyCon JP 2022 にて 15:10 から発表します。

みんなが画像生成AIと絵師との付き合い方を考える材料とかになればいいな。よろしくどうぞ！！https://t.co/9o2lsVLuzR

— Hirosaji / ひろさじ (@hirosaji)2022年10月15日

個人的に憧れていた方々からの反応も頂けて、感無量でした...。

今後の展望

これまでに積み上げたスクリプトで、簡単なサービスが作れたらと思っています。
パッと思いついたアイデアとして、例えばこんなサービスでしょうか。

  • イラストの評価（配色／ポーズ／焦点など）
  • イラストの添削（同上）
  • 戦略が類似したイラストの検索（同上）

これらをまとめて、CI/CDを構築するのも面白いかもしれません。
それから、AI絵師との付き合い方についても引き続き模索していくつもりです。

発表内容のメタサーベイ

発表後は対面／SNSにて、様々な属性を持つ方々（イラストレーター、エンジニア、デザイナーなど）と交流しました。
また、いくつかの参加者のイベント参加レポートで、私の発表への感想を載せていただきました。

多くの方が、私の発表内容を高く評価して下さっていました。
一方で、リファレンスの多様さに驚かれている方も多くいらっしゃいました。

すごい
「美術史とPythonと萌えとポリコレと生物学と性癖・・・」
様々な知識が集まってできた資料
（これはもう一種の論文と見て良いのでは）https://t.co/AKEn7OIBtN

— sokuoku (@sokuoku)2022年10月16日

こちらの方のツイートにもありますが、イラストはさまざまな分野の知識体系や経験則が凝縮してできた文化なので、その多くをカバーしようとするとサーベイ論文のような様相になってしまいます。
また、イラストは学術領域ではないので、あえてイラストの構造をロジカルに再定義する試みは新鮮に見えるようです。

そこで、イラストを科学的に捉えるために必要な知識や経験の全体像を描くべく、発表内容のメタサーベイに挑みました。

「イラストの心理戦略」のメタサーベイ

分量が長くなってしまったので、別の記事にしました。

他に類を見ない内容なので、読むのは大変だと思いますが、読んで後悔はしないと思います。興味ある方は是非。

「Python / ML」のためのメタサーベイ？

現状では、イラストの意味解析を研究する事例はありません。
私もイラストの技法書で調べたのちに、局所的に必要な実装を集めるので、メタサーベイは不可でした。すみません...。

一応、画像系のML事例はキャッチアップを続けているので、今後うまくトピックをまとめられたら共有します。

あとML系の情報収集に関連して、「創作xML」のDiscordにお邪魔できたのは良い機会でした。興味ある方はぜひ。

終わりに

久しぶりの現地会場での登壇は、すっかり新鮮な体験として楽しむことができました。
現地登壇のノウハウをすっかり忘れてしまっていたので、これからまた少しずつ取り戻していきたい気持ちです。

しかし、改めて新鮮な気持ちでPyConに臨んだのは、私だけではなかったはずです。

久しぶりの現地開催の準備・運用に尽力してくださったスタッフの皆さん、ありがとうございました。スタッフの皆さんも自ら楽しんで参加されていたこと。不意のトラブルにも実直に対応されてたこと。皆さんのPyConを支える真摯な振る舞いによって、私たちはカンファレンスを安心して楽しむことができました。

スポンサーの皆さんも、ありがとうございました。今回はいつにも増して、ノベルティの数が凄かったですね。また、現地に用意してくださったデモやLT、書籍の数々、どれも素晴らしかったです。休憩時間も関係なく、ずっとPythonに囲まれた気分でいられたのは、スポンサーの皆さんの支えがあったからこそでした。

私の発表やスライドを楽しんでくれた皆さんも、ありがとうございました。私の思いの丈をぶつけて、そこで返ってくる皆さんの反応はどれも優しく、勉強になることが多かったです。去年に引き続き、イラストレーターという別のドメインの発表内容も温かく見守ってくださり、本当にありがとうございました。

最後に、PyCon JP 2022を盛り上げてくださった参加者の皆さんにも感謝でした。
やはりカンファレンスは楽しい。そう思えたのは、楽しい空気を共有してくださった皆さんのおかげです。

ぜひ来年もまた、みんなで一緒にPyConを盛り上げましょう！

苦しんで取得するProfessional Cloud Architect

先日私は、Professional Cloud Architect（以下、PCA）の試験を受け、無事合格しました。

PCA取得のために要した期間は１ヶ月半、その中での勉強時間は250時間ほどです。
短い期間に集中して取り組んだ勉強でしたが、得たものは非常に多く、自分でも驚くほどの成長を実感しています。

なぜこの記事を書いたか

「PCAは簡単に取得できる」という記事をインターネットで散見します。
実際、次の記事にもあるように、現在のPCAはUdemyの模試を受ければ高確率で受かります。

その理由は、Udemyの模試のレビューにもあるように、８割ほど模試と酷似した問題が出題されるためです。

しかし、ただ取るだけの資格には何の価値もありません。
価値があるのは、資格を取るために学んだ知識です。

そこで今回は、PCA取得のために必要な正攻法の勉強を、私の経験をベースに紹介します。

受験のきっかけ

現在私が所属する企業がGoogle Cloud社のサポートを受けている関係で、全社的にGoogle Cloud認定資格を取得するプログラムを組んでいただきました。
私もそのプログラムに参加して、PCAを受験しました。

受験者(私)のスペック

  • Webエンジニア歴 ６年弱
  • AWS実務経験はあるが、Google Cloudは未経験
  • クラウドインフラの資格試験は初めて

クラウドインフラの知識はAWSでWebシステムを運用する実務経験から得たものしかなく、特にGoogle Cloudは全くの未経験でした。
なので、「Google Cloudの知識を得ること」と「クラウドインフラの広い知識を得ること」が私の受験の目標でした。

この記事の対象読者

PCAを取得するに足る能力を身につけて、PCAを取得したい方

良かった勉強法３選

私が実施した勉強のうち、最も効果的だと感じたのは次の3つです。

  1. Coursera や Google Cloud Skills Boost で基礎知識を付ける
  2. Google Cloud公式セミナーのアーカイブを見る
  3. ケーススタディを読みながら模試問題を解く

1. Coursera や Google Cloud Skills Boost で基礎知識を付ける

Coursera とGoogle Cloud Skills Boost (旧 Qwiklabs) は、インターネット上のPCA合格記でしばしば紹介されています。

Coursera は、世界中の大学や企業が教材を提供するオンライン学習サービスで、Google Cloud社も多くの教材を提供しています。
一方で、Google Cloud Skills BoostはGoogle Cloud社が運営するオンライン学習プラットフォームです。
どちらも日本語の講座が豊富にあります。

どちらを利用するにも多少の費用が掛かりますが、Google Cloudのカスタマーエンジニアの方にもこれらの教材をオススメされたこともあり、まず間違いない選択肢だと思います。

参考までに、私が利用した教材は次のとおりです。

Coursera

Google Cloud Skills Boost


これらの教材は、公式ドキュメントが要所にリンクされており、正確で最新情報が追いやすいようにデザインされています。
また、講座の数も充実しているため、PCAの出題範囲に合わせて広く学ぶにはこれらの教材がベストだと私は思います。

欠点として（元が英語のため）日本語訳に少し難がありますが、…根気強く読みましょう。

FYI: 日本語の分かりやすさは書籍が一番

読みやすい日本語で書かれた教材を求めるなら、日本人が著作したGoogle Cloud の書籍で学習するのが良いです。

ただ、書籍は出版された時点の最新情報が掲載されるため、ライフサイクルの早いGoogle Cloud 製品を学ぶのには慎重な教材選びが必要になります。
もし学習に書籍を選ぶ方は、その点をお気を付けください。

2. Google Cloud公式セミナーのアーカイブを見る

AssociateレベルのACE（Associate Cloud Engineer）と比較して、PCAはシンプルに出題範囲が広いです。

ACEはGoogle Cloud製品の技術的な仕様を問う問題が出題される傾向にあります。
PCAはACEの出題範囲に加えて、ビジネス要件を加味して「インフラをどう最適化するか」まで問われます。

そのためPCAの問題を解くには、技術要件とビジネス要件の両方に対応できる、より実際の設計業務に即した知識が必要になります。
となると頼れるのは、普段の業務で使う学習リソースと同じです。

普段の業務で困ったとき、何に頼るかと言ったら、やはりGoogle Cloud公式の学習リソースが良いでしょう。
オススメの公式リソースについては、Google Cloudのカスタマーエンジニアの方に直接教えてもらいました。

例として、「アプリを動作させるサーバを管理するサービスに、何を選べば良いか？」という問いは、PCAにも普段の業務にも頻出するテーマです。
このテーマに対し、現在（2022年夏）のGoogle Cloudには、次の５つの選択肢があります。

これらのサービスをどんな時に選べば良いか、という広い知識が必要な質問に対し、カスタマーエンジニアの方には次のスライド資料を紹介していただきました。

App ModernizationOnAirより（PDF Link）

また、DBの選び方に対しては、こちらのスライド資料を紹介いただきました。

Google Cloud内製化 Dayより（PDF Link）

これらのスライド資料は「Cloud OnAir」という、Google Cloud社が開催するセミナーイベントで使われたものです。
多くのセミナーがアーカイブとして、スライド資料とオンデマンド配信を公開しています。

ただ、残念ながらCloud OnAir トップページ には検索機能がありません。
何か欲しい知識があったら、「イベント名 →セミナー」の順でアーカイブを探す必要があります。
なお、アーカイブを探す際は、なるべく新しいセミナーを参考にすることをお勧めします。

もしあなたの所属している企業がGoogle Cloud製品を使っている、またはパートナー契約を結んでいるようであれば、担当のカスタマーエンジニアの方に相談すると良いでしょう。

FYI: そのほかオススメ資料

参考までに私は今回の勉強に際して、次のセミナーの資料を参考にしました。

  • GKE でマイクロ サービスの構築をする基礎から、高度なトラフィックルーティングと SLO 運用に至るまでの流れを解説（PDF Link）
  • データ分析におけるデータ ガバナンス（PDF Link）

3. ケーススタディを読みながら模試問題を解く

模試問題を解くのは、最後の最後です。
とことん勉強した後に、最後の腕試しとして取り組むと良いと思います。

PCAの模試は、現在（私の知る限り）次の2つがあります。

これらを解く際は、ぜひ本番だと思って受けてみてください。
これら模試で平均70点以上取れれば、PCAを合格するに足る実力を満たしたと言えるだろうと私は思います。

間違った問題や不明点は公式ドキュメントを読んで復習し、合格に必要な知識を盤石なものにしてください。

FYI: 勉強のためのワンポイント

Google Cloud認定資格の勉強していると、自然と良質なベストプラクティスに辿り着きます。
これは、Google Cloud製品がそれらベストプラクティスに則って設計されたサービスであるためです。

勉強中、もし知らない概念やキーワードを見かけたら、ぜひ適宜検索してみてください。
「基本ルール」と読み替えられるほどの素晴らしいベストプラクティスを学ぶきっかけが得られます。

Dockerセキュリティのベストプラクティス。
コンテナのアンチパターンを調べたら辿り着いた。https://t.co/EWFULMHSbU

良くできたベストプラクティスは「基本ルール」と読み替えられるくらい万能なので、見つけたら全部読む。

— Hirosaji (@hirosaji)2022年8月11日

（Google Cloud独自の用語もあるので、調べたら備忘録として、自分だけの用語集を作るのもオススメです）

おわりに

PCAを取得した自身の経験をもとに、取得までに必要な知識を得る手段をまとめました。
正直楽な手段は無いのですが、根気強く学べば、自分でも驚くほどの成長が見込めるはずです。

また、繰り返しになりますが、持っているだけの資格には何の価値もありません。
むしろ、知識を持たずに資格だけを持っている人は、マイナスに評価されることの方が多いと思います。
PCAのブランドのためにも、皆さんのキャリアのためにも、ぜひ実力を満たした上で資格取得に挑んでください。

P.S. 受験時の諸注意

夏のテストセンターはとにかく冷房が効いてるので、上着を持ち込むことをお忘れなく…。

ネコでもわかる set ±o pipefail

Bash（UNIX系のシェル）を実行する際、

$set-o pipefail
$set+o pipefail

というコマンドがおまじない的に使われているのをよく見ます。

今回は、担当することになったプロダクトのCIにこのコマンドが含まれていたこともあり、処理の詳細を調べました。
その覚書もかねて、解説記事を残します。

TL;DR

  • set ±o pipefail は、パイプラインを用いるコマンドの終了ステータスに影響する。
  • set -o pipefail を使うと、パイプライン内のいずれかのコマンドが失敗した場合、その失敗したコマンドの終了ステータスがパイプライン全体の終了ステータスとなる。
  • set +o pipefail を使うと、パイプライン末尾の終了ステータスがパイプライン全体の終了ステータスとなる。（デフォルトなので無くても良い）

解説

通常、bashはコマンドが実行されるたび、終了ステータス*1を更新します。

例として、簡単なシェルスクリプトを実行してみましょう。

#!/bin/shtrueecho$?falseecho$?# bashの終了ステータスは $? で確認できる

このスクリプトの実行結果は次の通りです。

01

一般に、コマンドが正常終了したら 0 、コマンドが異常終了したら 0 以外が終了ステータスが記録されます。

終了ステータスの範囲は 0~255 です。
よく使われるのは、次の予約済みのステータス*2でしょうか。

終了ステータス意味
1一般的なエラー
2ビルトインコマンドの誤用
126コマンドを実行できなかった
（例：実行権限がない）
127コマンドが見つからなかった
128exit に不正な値を渡した
（例：浮動小数点）
255exit に範囲外の終了ステータスを渡した

では、パイプラインを使う際の終了ステータスはどう更新されるでしょう。

#!/bin/shtrue |trueecho"$?"false |trueecho"$?"true |falseecho"$?"
001

終了ステータスには、パイプライン末尾のコマンドの終了ステータスが渡されます。

しかし２番目のパイプラインから分かるように、先頭のコマンドがエラーなのに、終了ステータスが正常終了を表す 0 になっては困るときが多いでしょう。
そんな時に、set -o pipefail が役立ちます。

では、set -o pipefail を冒頭で宣言して、同様のスクリプトを実行してみましょう。

#!/bin/shset-o pipefailtrue |trueecho"$?"false |trueecho"$?"true |falseecho"$?"
011

上記の通り、実行を失敗したコマンドの終了ステータスが変わっていることがわかります。
これで、パイプライン内のコマンドに対してもエラー制御しやすくなりました。

ちなみに、デフォルトはset +o pipefail です。
デフォルトですが、可読性のためにあえて明示的にset +o pipefail を宣言してもいいですし、スクリプトの途中で± を切り替えるために使っても良いかもしれませんね。

少しだけDeep Dive

set -o pipefail を使うと、パイプライン内で失敗したコマンドの中でもより後者の終了ステータスが反映されるようです。

#!/bin/shset-o pipefailfalse | not-exist-command |trueecho"$?"not-exist-command |false |trueecho"$?"
1271

また、set -o pipefail の他にも、set -e -u -x pipefail と色々とバリエーションがあります。
気になる方は次の参考リンクなどから調べてみてください。

*1:直前に実行されたコマンドの状態を表す数値（英: exit status）

*2:Exit Codes With Special Meaningsより抜粋

SREではないけど SRE NEXT 2022 を観て

先週末、オンライン開催のSRE NEXT 2022に視聴者として参加しました。

今回は、参加した動機と全体を通しての学びをまとめました。

イベント概要

  • 概要：SRE Practiceに関心を持つ人のためのカンファレンス
  • 日時：2022年5月14日（土）～ 2022年5月15日（日）
  • 会場：オンライン（ZOOM）
  • テーマ：SRE DIVERSITY
  • 公式 HP：https://sre-next.dev/2022/

参加した動機＆全体を通しての学び

私はSREではなく、SREからサポートを受ける開発チームに所属するサーバサイドエンジニアです。
ここ最近、SREが請け負ってくれる仕事の線引きが曖昧に感じたので、今回はその境界線を判断できるようになるため、各セッションを視聴しました。

全体のセッションを通してみると、SREはサポートする開発チームに常駐すべきではなく、そのチームが自律的に信頼性を高める行動を取れるようになるまで一時的に支援すべき、という一つの結論を述べるプラクティスが多かったと感じます。

例えばメルカリ社は、開発チームがSREチームに依存しすぎないよう、サポート先をローテーションしているそうです。

メルカリのEmbeded SREは、Embeded先のローテーションで、不用意な依存関係を回避しているとのこと。#srenext#srenextAhttps://t.co/J5n2kkSs1Ypic.twitter.com/7y9Geyd1Hv

— Hirosaji / ひろさじ (@hirosaji)2022年5月15日

ただ、期間内に十分なサポートをすることができなかったこともあり、その際はサポート期間を延長するといった対応が必要だったとのこと。

QAセッションにて。
Embededするのは半年ほど。
短期間のEmbededによるデメリットの一つとして、Embeded先の規模が大きくてonboarding不全になってしまったケースがあった（その際は、期間を延長したらしい）

— Hirosaji / ひろさじ (@hirosaji)2022年5月15日

また、サポート不足に関連した別の失敗例もあります。
例えば、スタディサプリの事例を紹介した @chaspy さんのセッションにて。

SREチームは信頼性を高める文化を浸透させるのが役目で、常駐すべきではない。
開発チームは、SREチームのサポートに依存してはならない。

これ、開発チーム側が特に心に留めなきゃいけないことだなぁ。#srenext#srenextBhttps://t.co/yaA4QLSXJupic.twitter.com/4FCaa5IZ8O

— Hirosaji / ひろさじ (@hirosaji)2022年5月15日

SLI/SLOを策定したが、SLO違反の際に開発チームが適切な行動ができなかった、との失敗例をあげていました。
これは取るべき意思決定に必要な権限や予算、そして関係者の理解が足りなかったために起こってしまったと述べていました。

この対策として、 @chaspy さんは信頼性を重要な事業戦略の一つに組み込むべく組織改革をしたり、草の根活動で文化醸成をしたりしているそうです。

つまり、ここで私が得たかった結論として、
「いつまでも、あると思うな、SREサポート」（字余り）
ということをサポートを受ける側は胸に刻んでおかないといけないなぁ、と思いました。

特にSLO違反やインシデント発生時のトリアージ、エスカレーション、アサインは開発チーム内で自律的にできるようにならなければと思います。
そのための基盤づくりや指標選びの相談はSREに頼ってもいいが、それらを運用で使うのは俺たちだぞ、というマインドでSREと付き合っていくのが健全だろうと、私は結論付けました。

SRE NEXT 2022、参加してよかったです。
むしろ、私のような開発チームに身を置くエンジニアこそ参加すべきだなぁ、と今になって思います。

おまけ

現時点で、各セッションの動画は公開されていないようです。ただ個別に共有されたスライドを、こちらの方がまとめてくれていました。

Day1のスライドまとめましたーhttps://t.co/gCNsi73pqM#srenext

— yebis0942 (@yebis0942)2022年5月14日

もし参加できなかった、または観たいセッションを見逃したという方がいたら、こちらからスライドだけでも覗きにいくと良いと思います。

容量順に各ディレクトリの名前と容量を並べたCSVをつくる

注：かなり雑な実現方法の備忘録なので、過度な期待は禁止です₍₍⁽⁽🌵₎₎⁾⁾


先日、ハードディスクの空き容量を増やすため、容量の大きいディレクトリを調べるための方法を探していました。
いくつかの方法を組み合わせれば、特にプログラムを組むことなく容量の大きいディレクトリを発見できるようです。

今回は、カレントディレクトリ内のディレクトリの容量を、容量順に並べたcsvを作るまでの手順を紹介します。

手順

1.PowerShellで容量を出力する

PowerShellのGet-Childitem コマンドを使うことで、ディレクトリの容量を取得することができます。

カレントディレクトリ内のすべてのディレクトリを取得するコマンドは次の通りです。

Get-Childitem -Path ./ -Directory | ForEach-Object -Process{Write-Host $_; Get-Childitem -Path $_ -Recurse | Measure-Object -property length -sum | Format-List count, sum}

参考：[備忘録]Windows10：フォルダ毎の容量を調べる方法 | CEOブログ

上記のコマンドを実行したら、標準出力結果をコピーして、適当なテキストエディタに貼り付けてください。

●PowerShellで標準出力の行数が足りない場合
こちらの記事を参考に、行数の上限を増やすと良いです。
コマンドプロンプトの最大バッファリング行数を約3万2000行まで拡大する：Tech TIPS - ＠IT

2. 出力結果を整形してCSVで保存

コピーした出力結果をエディタに貼り付けたら、エディタの置き換え機能を使って、テキストを整形します。

置き換えは、次の４回です。

  1. \n\n\n ->\n
  2. \nCount : ->,
  3. \nSum : ->,
  4. \n\n ->\n

置き換えが終わったら、好みのヘッダーを追加（例:Name,Count,Sum）して、CSVとして保存してください。

3. 保存したCSVのデータをExcelで並べ替える

保存したCSVをExcelで開き、Excelの機能で並べ替えます。

例えば、Excelのデータタブにあるソート機能を使うなどです。
もしわからなければ、「Excel ソート」などで検索して調べてみてください。

おわりに

かなり雑な方法ですが、これでたくさん容量を食っているディレクトリを探すことができます。

もし同様の解決ができる便利なスクリプトがあったら、ぜひ教えていただけると嬉しいです。

注目記事
検索
スポンサーリンク

引用をストックしました

引用するにはまずログインしてください

引用をストックできませんでした。再度お試しください

限定公開記事のため引用できません。

読者です読者をやめる読者になる読者になる
[8]ページ先頭
©2009-2025 Movatter.jp