AWS Certified Solutions Architect Professional の更新試験に合格しました

少し前の話しですが、AWS Certified Solutions Architect Professionalが有効期限をむかえるということだったので更新のために受験しました。 結果は無事に合格&スコアアップすることができたのでどうやって勉強したかを残しておきます。

自身のスペック

  • AWS
    • 6年くらい
    • 仕事で本格的に触り始めたのは4年前
  • 資格
    • AWS Certified Solutions Architect - Associate
    • AWS Certified Developer - Associate
    • AWS Certified Solutions Architect - Professional
  • 仕事
    • SREです。ここ2年くらいはkubernetesを中心にAWSGCPを触っている

とりあえず模試を受けた

模試の結果は合格経験があるもののスコアは55%で手応え全くなしという状態でした(55%は運だと思っている...)。 ここから落ち込んだのか、なぜかやる気がなくなってしばらく無の時間が続き試験2ヶ月前から本格的に勉強を開始しました。 直前に一気に勉強する体力がなさそうだったので1冊の本を時間をかけて勉強することにしました。

読んだ本

AWS認定ソリューションアーキテクト-プロフェッショナル~試験特性から導き出した演習問題と詳細解説~ | 平山毅, 堀内康弘, 福垣内孝造, 岡智也, 新村俊介, 岡崎靖浩, 池田大, 澤田拓也, 津山晃一, 鳥谷部昭寛, 早川愛 | 工学 | Kindleストア | Amazon

たまたまAmazonにオススメされた本ですが演習問題が多く問題毎の解説がよくまとまってそうだったのでこの本で勉強することにしました。 前回、はじめて受験したときは問題文が長く時間内に全部の問題を解くことができませんでした。 なので多くの問題に触れて問題に慣れることが必要だと思い演習問題中心の本を選びました。

約2ヶ月の間、平日は1H、休日は2Hを上限と決めて毎日やった(エルデンリングが発売されたためこれ以上の時間確保は無理)

Black Belt オンラインセミナーを利用

普段利用しないサービスについては単語もまったくわからない状態だったのでAWS Black Belt オンラインセミナーの資料やYoutubeを利用しました。 特にDirectConnect, Organization などですね。

aws.amazon.com

模試(2回目)

受験2週間前に再度、模試を受けた。初回受験時は有料の模試だったのですがいつの間にかAWS Skill Builderで模試が無料で受験できるようになっていました!

dev.classmethod.jp

20問の問題を解くことができて、ログインすれば問題何度も見返すことができます。 問題の解説もあるので前の模試 勉強の成果もありスコアは80%でなんとかなりそうな感じになってきました。

テストの手応え

  • 全問解くことがきて時間が結構余った
  • ほとんどの問題を理解して対応することができた。手応えがなかった問題は1問くらい
  • それなりにスコアアップできた

というわけで無事に合格できてよかったです(結構不安だったので)。 3時間のテスト時間で問題文の長い問題を素早く解き続けるのは知識も必要だけど、ある程度の訓練が必要だなと感じました。 試験の勉強を通して忘れていた制約や便利なアーキテクチャを思い出せたのも良かったです。

Auroraのインプレースアップグレードは手動で再起動するまでデフォルトパラメータグループで動作するため注意

背景

先日、Amazon Aurora MySQL version 1 ( MySQL 5.6 互換 ) のEOLが2023/02/28に予定されました ( 以降、Aurora MySQL v1と記述 )。 2022/09/27 からAurora MySQL v1の作成ができなくなります。 Aurora MySQL v1で動作しているクラスターをAurora MySQL v2 ( MySQL 5.7 互換 ) or Aurora MySQL v3 ( MySQL8.0 互換 )にバージョンアップする必要があります。

docs.aws.amazon.com

アップグレードの方法

アップグレードの方法は主にインプレースアップグレードとBlue/Greenアップグレードの2種類の方法があります。

インプレースアップグレード

docs.aws.amazon.com

利用中のクラスタでアップグレード処理を実施します。インスタンスのシャットダウンが発生しますが手順はシンプルです。エンドポイントはそのまま保持されるため変更の手間もありません。

Blue/Greenアップグレード

aws.amazon.com (英語ドキュメントしか無さそう)

新しくMySQL5.7のクラスタを構築して、MySQL5.6のクラスタからデータをレプリケーションすることで2つのクラスタが同じデータを保持している状態を作ります。最終的にエンドポイントの切り替えによってバージョンアップを実施します。インプレースアップグレードよりもダウンタイムを少なくすることができます。

インプレースアップグレードを実施して分かった問題

インプレースアップグレードはとてもざっくりですが↓の図のような流れでアップグレード処理が走ります。

f:id:masayosu:20220304172637p:plain
インプレースアップグレードの流れ

問題なのは↑の赤いPending Reboot (再起動保留中) の状態で、再起動を待ちながらDBインスタンスは起動しています。 このPending Reboot (再起動保留中) の状態ではデフォルトのパラメータグループ( default.aurora-mysql5.7 )でAurora が動作している状態です。そしてカスタムパラメータ設定を適用するには手動で再起動を実施する必要があります。 これはドキュメントにも下記のように書いてあります。

アップグレードプロセス中にカスタムパラメータグループを指定した場合は、アップグレード終了後にクラスターを手動で再起動する必要があります。再起動すると、クラスターがカスタムパラメータ設定の使用を開始できます。

つまりアプリケーションを起動した状態でインプレースアップグレードを実施した場合、カスタムパラメータグループの内容によってはサービス影響が発生する可能性があります。

対策

アップグレードの前後でアプリケーションを停止する

インプレースアップグレードの所要時間はデータ量やクラスターのビジー状態によって変わってくるのでアプリケーションの停止時間が読みにくいというところはあります。

Blue/Greenアップグレードを採用する

Blue/Greenアップグレードはクラスタを新しく構築するためエンドポイントを参照している箇所を変更する必要があります。参照している箇所が把握できていなかったり、変更箇所が多かったりすると結構大変な作業になりそうです。

まとめ

  • 2023/02/28 に Aurora MySQL v1 が EOL を迎えます
  • アップグレードの方法はインプレースアップグレードとBlue/Greenアップグレードの2種類
  • カスタムパラメータを利用してインプレースアップグレードを行う場合には注意が必要

はてなにおけるCloudNative推進会の活動について

こんにちは。

はてなでSREをやっているid:masayosu です。

この記事ははてなエンジニアAdvent Calendarの15日目のエントリです。

サブ会と呼ばれている組織の一つ、CloudNative推進会について紹介します。

 

サブ会について

はてなにはサブ会という集まりがあります。

サブ会というのは所属する組織とは別で、あるテーマに興味を持ったメンバーの集まりです。テーマに関わる知見を深めていくような活動を行い、その内容を社内に共有するような働きをするため会社公認の組織です。

サブ会には以下のようなメリットがあります。

  • 予算要望をあげることができる
  • 自分の興味あるテーマについて業務時間を利用して調査することができる
  • 個人の成果目標の一部にサブ会での活動成果を含めることができる

個人調査やボランティア活動になりがちな活動の成果をフィードバックすることで会社に活動を認めてもらえるといった制度です。

 

CloudNative 推進会について

はてなの技術グループでは2019年からコンテナ化を推進していて、新旧さまざまなサービスをコンテナで運用するようになりました。CloudNative推進会は2019年に発足され、コンテナ化をサポートするための活動を継続して行っています。

はてな社内で課題となっているテーマを半期に一度選定して、技術グループのサポートとなるような成果物をアウトプットしています。

 

これまでの活動

活動テーマを選定するために社内のサービスチームのコンテナ化の現状をヒアリングました。そのヒアリングの結果と Cloud Native Trail Mapを見て、はてな技術グループの現在地を確認します。そして解決できたら一番嬉しい題材を半期のテーマとして選定します。

これまでの活動で、社内向けに出した成果物を3つ紹介していきます。

 

コンテナチェックリスト

コンテナチェックリストとはアプリケーションをコンテナ化する際のノウハウをチェックリスト形式でまとめたものです。

アプリケーション対応、Dockerfile、イメージ管理、CI/CD、オーケストレーション、モニタリング、ログといった項目毎にチェックリストを作成しています。

アーキテクチャの設計段階やリリース前のチェックとして各サービスチームに利用してもらっています。

 

f:id:masayosu:20211210182919p:plain

 

CloudNative CI/CD

CI/CDの定義とそのプラクティスをまとめたドキュメントです。

CI/CDのShipプロセスを工程(ステージ)に分割して一般的なワークフローを提示しています。

ツールとしてのCI/CDの理解ではなく抽象度を上げて理解することで各ステージでの役割と責任範囲を明確にすることができました。適切な役割でステージを分割できるとリリースサイクルを早めたりリリースリスクが低減できるメリットがあります。

f:id:masayosu:20211210183808p:plain

 

CloudNative Batch Processing

社内においてWebアプリケーションのコンテナ化についてはノウハウが蓄積されてきていたのでBatchに目を向けてノウハウををまとめました。CloudNativeな環境でBatchを動作させる場合、Batchアプリケーション以外の管理( Event Source, Monitoring, Storage, LogCollector)はプラットフォームが持つマネージドなサービスを頼ることができます。

ただ、それらのマネージドなサービスを利用する際に意識するポイントがいくつかあります。このあたりの話については先日のHatena Developpers BlogでもCloudNative推進会のメンバーでもある id:tkzwtksさんの記事でも触れられています。

developer.hatenastaff.com

 

f:id:masayosu:20211210184626p:plain

まとめ

CloudNative推進会の活動について紹介しました。

CloudNative推進会は技術グループに所属する異なったロールのメンバーが集まるため、様々な技術ジャンルについて活発に議論できる場です。

これからも良い成果が出せるようにやっていくぞ!

 

さいごに

はてなでは全方位的にエンジニアを積極採用中です!

一緒にCloudNativeについて議論しましょう!

hatenacorp.jp

developer.hatenastaff.com

 

明日のはてなエンジニアAdvent Calendarid:kouki_dan さんです。

宜しくお願いします!

株式会社はてなに入社しました

7/1付けで株式会社はてなに入社しました。

前職での AWS の利用経験と SRE としてやってきたことを認めていただき id:hayajo_77 さんにチャンスをいただくことができました。id:hayajo_77 さんとは以前も新潟で同じ会社で働いていたので、本当に感謝しています。チームは別ですが、また一緒に働くことができて楽しみです。

ロールはこれまでと同じ SRE です。SREing について、これまで以上に掘り下げて実践していく必要がありそうです。技術的にも幅を広げることができそうなので、ひとつずつ整理しながら前進していきたいと思っています。

コロナ禍という状況だけど、リモートでオンボーディングしたり普段は体験できないことを経験しています。殆どのチームメンバーにはリモートでしか会えないので早くコロナウィルスが収束することを祈っています。

いつになるか分からないけど京都オフィスにもお邪魔したいです。

早くも知識の洪水でパンク状態ですが、焦らず楽しみながらやっていこうと思います。

がんばるぞー!おー!!