1 Minute Tips

投稿者: sumito.tsukada

  • Go言語での正規表現

    Go言語での正規表現

    はじめに

    Go言語内の文字列の判定で正規表現を使う際の“regexp”ライブラリについてまとめる

    使い方

    MatchString

    正規表現のフォーマットに沿った文字列か確認し、True/Falseを返す

    	match, _ := regexp.MatchString("b([a-z]+)a", "banana")
	fmt.Println(match)

    結果

    true

    しかし、この書き方では複数の文字に対してチェックしたい場合、都度正規表現を書かなくてはならない。

    MustCompile

    以下の書き方をすることで正規表現の定義は一度のみでよくなる

    	r := regexp.MustCompile("b([a-z]+)a")
	ms1 := r.MatchString("banana")
	fmt.Println(ms1)
	ms2 := r.MatchString("apple")
	fmt.Println(ms2)
	ms3 := r.MatchString("orange")
	fmt.Println(ms3)

    結果

    true
false
false

    FindString

    MustCompileの中でURIを正規表現で定義し、
    FindStringで、そのルールに収まっているか確認をするという使い方もできる。
    	r2 := regexp.MustCompile("^/(edit|save|view)/([a-zA-Z0-9]+)$")
	fs := r2.FindString("/view/test")
	fmt.Println(fs)

    結果

    /view/test

    もしヒットしない場合は、結果を返さない。

    FindStringSubmatch

    格納されるデータはスライスで入っているので、一つ一つ取り出すことも可能。

    	fss := r2.FindStringSubmatch("/view/test")
	fmt.Println(fss[0])
	fmt.Println(fss[1])
	fmt.Println(fss[2])

    結果は以下の通り

    /view/test
view
test

     

  • プロダクションレディマイクロサービスを読んだ

    プロダクションレディマイクロサービスを読んだ

    はじめに

    オライリーのプロダクションレディマイクロサービス（原書: Production-Ready Microservices ）を読んだ。

    本記事はその書籍を通してえられた事についてまとめた。

    本記事の対象者

    • マイクロサービスに興味を持っている人
    • プロダクションレディマイクロサービスに興味を持っている人

    なぜ読もうと思ったか

    ４月からマイクロサービスで動いている共通基盤チームを担当することになり、今まではなんとなくマイクロサービスについて理解はしていたが、きちんと書籍を通して学んだ事がなかったので、比較的時間の作りやすいゴールデンウィークの課題図書として読み、ブログを記載する事で理解を深めようと思った。

    本書を通して何を得られたか

    マイクロサービスのメリットはそれなりに知っていた。大きなところだと、システムを疎結合にする事により、変更の容易性を得られる事にあると思っていた。

    その前提の状態から本書を読み、得られたポイントは以下の通り。

    ドキュメント

    マイクロサービスを導入すると技術的負債が増える傾向がある。本書によると、一種のトレードオフとされてある。

    その対処法を要約すると、ドキュメントの維持・管理とメンバーの理解にあるという。組織的に明確化され、構造化されていれば技術的負債を引き起こす混乱や、意識の欠如、アーキテクチャの理解の欠如を払拭する事ができるとのこと。

    確かに、自分もドキュメントはマイクロサービスでなくても重要であり、しかし更新が後手後手になってしまい陳腐化してしまうプロジェクトやチームを多数見てきた。

    なお一層、ドキュメントを最新にしチームで共有するというのが必要になりそうだ。

    ドキュメントのポイントは以下の通り

    • 包括的か
    • 定期的に更新されているか
    • マイクロサービスの説明、アーキテクチャ図、連絡先、オンコールの情報、重要情報へのリンク、サービスのリクエストフロー、エンドポイント、依存関係、FAQなど盛り込まれているか
    • ドキュメントがチーム内でよく理解されているか
    • 簡単に検索できるか

    注意すべきはREADME。これは本番対応のドキュメントではない。

    組織的な理解

    チーム内の全ての開発者がマイクロサービスの本番対応についての質問に答えられ事ができるかが重要になる。

    マイクロサービスのレビュー、監査は頻繁に行われる必要がある。

    本番対応の監査プロセスも確立されている必要がある。

    成長の判断基準

    サービスがサポートできるRPS（毎秒平均リクエスト数）、QPS（毎秒平均クエリー数）を尺度とする。

    将来サービスに必要とされるRPS/QPSがどれくらいになるかを予想する。

    この指標は量的な成長の判断基準を決めるときの判断材料になる。

    しかし、RPS/QPSの情報は、成長の判断基準を初めて計算した時のマイクロサービスの状態に左右される事が多い。

    マイクロサービスは単独で動いているわけではなく、大きなエコシステムの一部として動いているという事を念頭に置く事が重要。

    マイクロサービス内のプログラムは何でも良いのか

    並行性とパーティション分割（タスクがただ小さな部品に分割されているだけではなく、並列処理できるようにする事）を実現しようとし、非同期フレームワークを使いたい場合、並行性とパーティション分割のために構築された言語である、C++、Java、Goなどが望ましい。仮にPythonでサービスを書くと、スケーラビリティやパフォーマンスを妨げる無数のボトルネックが作られ、それらの悪影響を緩和するのが困難になる。

    並行性とパーティション分割は、相乗効果でマイクロサービスのスケーラビリティとパフォーマンスに影響を与える。

    監視の主要なメトリック

    ホスト、インフラ周り

    • CPU
    • MEMORY
    • スレッド
    • ファイルディスクリプタ
    • データベース接続

    これらの監視はモノリシックなアーキテクチャでも定番だ

    マイクロサービスの主要メトリック

    • 言語固有メトリック
    • 可用性
    • SLA
    • レイテンシ
    • エンドポイントの成功
    • エンドポイントのレスポンス
    • エンドポイントのレスポンス時間

    上記の通り、マイクロサービス単体の外形監視が特に必要になる。

    これらをダッシュボードにまとめれば、チーム内で共有しやすくする。

    ダッシュボードは、わかりやすいか、主要メトリックがまとまっており、ダッシュボードを見ただけでマイクロサービスが正しく動作しているか、などが表現されているかが重要になる。

    読み終わって感じた事

    担当しているマイクロサービス基盤チーム内対応できてないポイントが、すべき理由とともに明確になった。

    いきなり全ては難しいので、優先順位を決めてチーム内で話し合って、現実的な所から改善して行く必要がある。

     

    本書はどの現場でも利用できそうな、汎用的なチェックリストも用意されており、チェックリストから読んでいっても、読者の環境をベースにイメージする事ができると思う。

     

  • AWS Solutions Architect受験記録

    AWS Solutions Architect受験記録

    はじめに

    AWS ソリューションアーキテクト（アソシエイト）を合格する事ができた。

    振り返りも兼ねて、まとめたいと思う。

    きっかけ

    ４月AWS Certified Solutions Architectを取得しようと心に決めた。

    理由は以下の通り。

     

    • 入社以来ずっとインフラチームにいたが、４月からマイクロサービスを推進する別チームを担当することになった。今まで仕事を通じて学んだ事を形にしたかった。
    • インフラチームを離れると言っても、AWSを使わなくなる訳ではない。むしろ、積極的に活用する立場になる。どのような構成で設計していけば良いのか、今回の勉強で新たな視点を得たかった。
    • さらなる運用費削減の構成を学ぶ事で、ランニングコストを削減に貢献したいと思った。
    • 今から作ろうとしているシステムの構成で、ベストプラクティスを学べる事ができるかも。
    • 本試験を通じて得られる知識をチームに還元し、チーム全体のレベルをあげるキッカケが作れるかも。

    勉強前の状態

    仕事を通じ、会社のシステムをAWSへ移行するプロジェクトを担当させていただいた。

    ただし、チームで取り組んだので、自分が全てを担当した訳ではない。

    正直言うと、他のメンバーが担当したところは「そーゆーものなのかー」程度だった。

     

    チーム全員がほぼAWS未経験。2つの国を横断するサーバーをAWSに移行した話。

    このプロジェクトではクラスメソッドさんに数々の有益なアドバイスを戴いた。やっぱクラメソさんすごいよ。

    何の教材を使ってどのくらい勉強したか

    定番の黒本

    勉強時間は10時間程度だったと思う。

    この本が特に役立ったのは、S3のバケットタイプ。

    とりあえずスタンダードやGlacierを使っていたけど、それ以外のタイプはあまり詳しくなかった。

    仕事ではバックアップしたファイルをS3に格納したりしているが、今回得た知識を使って去らなくコストダウンをする事ができそうだ。

    その他、EBS最適化、DynamoDB アクセラレーター、他アカウントとの統合など参考になった。

    問題集

    とにかく隙間時間に勉強したかったので、スマホでも勉強できる教材が欲しかった。ヤフオクに売ってる380問くらい入っているのを買った。

    正直結構難しい、「このレベルが実際の試験の問題なのかも」と思い面喰らった。

    なので、とにかく正解率が9割を超えるくらいやり込んだ。おそらく20時間は費やした。

    しかし、実際の試験ではここまで難しい問題は出なかった。

    Udemy

    UdemyでAWS取得コースがあったので、セール中に買って隙間時間にやったが、小テストがスマホ（私がiPhone 7だからか？）に対応していないようで、小テストの度にPCで行なっていたが、次第に億劫になってしまい、最初の５時間程度やっただけでやらなくなってしまった。しかし、コンテンツ自体はとても良質なので、いい教材だとは思う。

    だけど、自分としてはセミナーをじっくり聞いてテストを解くというよりは、テストを先に解いて分からないところを講義を聞くというスタイルじゃないと、眠くなってしまう体質なので自分にはあわなかった。

    https://www.udemy.com/aws-associate/

    AWS Blackbeltの資料

    おそらく3時間程度。

    EC2,VPC,RDSなど、移行の時に使ったり、日々使っているものについてはザーッと流して読んだ程度。

    逆にKinesisやRedshiftは業務で使っていないので、概要を掴んだ。

    Kinesisのチューニングポイントなど、Blackbeltを目を通すだけでも有益だ。

    勉強のアウトプット

    手前味噌ながらメモをサービス毎に本ブログで書いた。

    自分があらかじめ知っていたところは記載しておらず、知らなかったところ、もしくは理解が乏しいところを読み返すためにまとめた。

    そのため、たった１行の記事もある。。

    https://tsukada.sumito.jp/category/tech/aws/aws-certified-solutions-architect-associate/

    （メモです。間違ってるところあったらごめんなさい、直します）

    実際の試験

    自分があまりに構えすぎていたのもあるかもしれないし、たまたま自分の運が良かっただけかもしれないが、難しい問題はそこまでない。

    問題は日本語でも選べるが、ちゃんと読まないと引っかかってしまうものもある。

    幸い、問題毎に日本語・英語を選べる事ができたので、自分の理解に間違っていないか、日本語・英語の両方で確認した。

    試験時間は130分もある。この確認をしても時間は十分に余った。

    試験後の感想

     

    昔Ciscoの試験やOracleの試験を受けた際は「合格・不合格」の紙はもらえたが、それがなかったので全く実感がわいてない。５営業日にメールで連絡来るらしい。

    また、試験の翌日、AWS認定サイトにログインしたら無事合格証のPDFをダウンロードする事ができた。

     

    参考情報

    AWS Solutions Architectを取得するだけでなく、AWSについて体系的に学ぶことができるのでおすすめ。

  • Trusted Advisor

    Trusted Advisor

    カテゴリーの提供情報

    • Performance
    • Cost optimization
    • Security
    • Fault torelance

     

  • ElasticCache

    ElasticCache

    Web sessionデータをリレーショナルデータベースに格納する代わりに、Amazon ElasticCacheを使用する利点

    • セッションデータの読み取り・書き込みパフォーマンスの向上
    • データベースインスタンスの負荷軽減
  • DynamoDB

    DynamoDB

    概要

    ユーザセッション状態を格納する事など可能。耐久性と低レイテンシを備えた構造化ストレージ

    ユースケース

    • Web sessionの管理
    • JSONオブジェクトの保存
    • Amazon S3 オブジェクトのメタデータの保存

    EC2インスタンスにデプロイされたアプリケーションがDynamoDBテーブルに書き込むため必要な作業

    • DynamoDBテーブルへの書き込みを可能にするIAMロールの作成
    • IAMロールを含む起動設定でEC2インスタンスを起動

     

  • ELB

    ELB

    トラフィックにばらつきがある場合

    一部のインスタンスが他のインスタンスより、多くのトラフィックを処理している場合、

    ELBでクロスゾーンロードバランシングが設定されていない可能性がある。

     

  • サポートについて

    サポートについて

    ビジネスレベルのプレミアムサポート応答時間は1時間

  • アクティビティの記録とアクセス権の管理

    アクティビティの記録とアクセス権の管理

    ユーザのアクティビティの記録

    Access AdvisorのService Last Accessed Data

    IAMエンティティ（ユーザ、グループ、ロール）が、

    最後にAWSサービスにアクセスした日付と時間を表示する機能

    Credential Report

    利用日時などが記録されたIAM認証情報にかかるレポートファイル

    AWS Config

    IAMのユーザ、グループ、ロール、ポリシーに関して変更履歴、

    構成変更を管理、確認することができる機能 

    AWS CloudTrail

    AWSインフラストラクチャ全体でアカウントアクティビティをログに保存。

    継続的に監視し、保持することができる。

    アクセス権限を一時的に付与する

    AWS Security Token Serv ice(STS)

    動的にIAMユーザを作り、一時的に利用するトークンを発行する

    Temporary Sercurity Credentials

    AWSに対して一時的な認証情報を作成する仕組み。

  • AMI

    AMI

    AMI起動タイプ

    すべての AMI が Amazon EBS-Backed と Instance Store-Backed のいずれかに分類されます。前者は、AMI から起動されるインスタンスのルートデバイスが、Amazon EBS スナップショットから作成される Amazon EBS ボリュームであるということです。後者は、AMI から起動されるインスタンスのルートデバイスが、Amazon S3 に格納されたテンプレートから作成されるインスタンスストアボリュームであるということです。

    https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ComponentsAMIs.html#storage-for-the-root-device

     

    解説の図は以下がわかりやすい

    Instance store-Backed

    EBS-baced

    https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/RootDeviceStorage.html

     

    その中でも、準仮想化 (PV) およびハードウェア仮想マシン (HVM))というのが存在する。

    種別でいうと、以下の４種類が存在している

    • HVM instance Store
    • PV instance Store
    • HVM EBS-Backed
    • PV EBS-backed

    HVMについて

    この仮想化タイプでは、ベアメタルハードウェア上でオペレーティングシステムが動作するのと同様に、修正を行わなくても仮想マシン上でオペレーティングシステムを直接実行することができます。

    （中略）

    HVM のゲストは、ホストシステム上の基盤となるハードウェアへの高速なアクセスを可能にするハードウェア拡張を利用できます。

    　PVについて

    特別なハードウェア拡張 (拡張ネットワーキングや GPU 処理など) を利用できません。従来、PV のゲストは HVM のゲストよりも多くの場合にパフォーマンスが向上しました。ただし、HVM 仮想化の機能強化や HVM AMI で PV ドライバが利用可能になったことにより、このようなパフォーマンスの向上はなくなりました。PV-GRUB の詳細や Amazon EC2 での使用方法については、「独自の Linux カーネルを有効にする」を参照してください。

    次の旧世代のインスタンスタイプは、PV AMI をサポートします: C1、C3、HS1、M1、M3、M2、および T1。現行世代のインスタンスタイプは PV AMI をサポートしません。

    次の AWS リージョンでは、PV インスタンスをサポートしています: アジアパシフィック (東京)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、欧州 (フランクフルト)、欧州 (アイルランド)、南米 (サンパウロ)、米国東部（バージニア北部）、米国西部 (北カリフォルニア)、米国西部 (オレゴン)。

    https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/virtualization_types.html

    上記より抜粋

    まとめると、HVMはOSを直接操作することができるので、低レイテンシで操作が可能。

    一方、PVはエミュレートするようなイメージで、ワンステップを挟む必要があるので、HVM以上のパフォーマンスは出せない（と思う）また、サポートしていないインスタンスタイプがある。