Gatsby+Netlifyで作ってたブログをはてなに移行しました

ブログの内容そのものはたまーに投稿しておりましたが、はてなブログからのPOSTはこれが初めてになります。
元々はGatsby+Netlifyで作っていた技術ブログをはてなブログに移転、リブートしました。なんでタイトルの通りのことをしたのかは後ほど書きます。

画像は目の前にあったものを適当に引っ張ってきました()

 

一応のご挨拶

Twitter等では「もつ」という名前で存在しています。普段はアニメの聖地巡礼やらウマ娘(+競馬の悲鳴)をつらつらとやりたい放題に投稿していますが、時々エンジニアっぽいこともつぶやいてます。

 

現職はSIer、会社はBtoBがメインなのでほとんどの人が聞いたことないですが、人数だけ見ると大手企業らしいです()。新卒から部署(名称変更は死ぬほどしてるけど)は変わらず、元々監視運用をやっていたのが現在はServiceNowというSaaSに関わっています。自称インフラエンジニアですが、ServiceNowはどちらかというとアプリ側・・・。

JAWS-UG 初心者支部の運営もやってます。好きなサービスはS3でストレージ系が好みで、昔から保管とかそういったのが好きなことが理由です。


言語は残念ながらかけません。実業務でほぼ書くことがないのもありますが、初手のJavaでトラウマになりました。PythonとJSは多少読み書きできる程度で、Golangとかはちょっと読める程度。HTML,CSSをここに入れるかは悩みどころですが、メインブログのテーマをいじるのでよくお世話になっています。

JAWS-UGでは当然本名で参加しているため、時々顔が出てたり名前が出てたりしています。本名でググると色々出てきますが、大体ボクデス。昔から広報とかアウトプットに興味があってやってきたのが影響しています。

 

なんではてなからGatsbyじゃなくて逆をやったの?


理由は2つほど。ちょっとネガティブなですかね。


Githubを使っての投稿が面倒になった


エンジニアとして「お前は何を言っているんだ」と言われかねない理由ですが、そのままです。Githubは残念ながら業務では用がなく、個人での利用をしています。マークダウンで書くことは別に苦ではないのですが、面倒と感じるようになり後述の理由を含めて辞めることにしました。

・上記を理由にアウトプットが遅くなる


僕の性格は結構せっかちです。聖地巡礼のブログもまあまあ早めにやってるのですが、性格も起因しています。また、技術的なことや勉強会などのアウトプットもなる早で出していくほうが目にとまるし、何より本人の情熱がなくなっていきます。
一手間でも面倒と感じるとやらなくなる悪い癖があるので、それならば投稿することだけを考えるようにしたいなと思うようになりました。

 

フルマネージドサービス、私の好きな言葉です

 

Gatsby+NetlifyもWordPressに比べたら管理の手間もないし、十分にカスタマイズができるからそれでも良かったのですが、技術ブログの目的はアウトプットをなるべくすること。だとしたらブログサービスを利用する方が早いですし、どうせはてなブログProがあるなら複数ブログ管理もこっちでしたほうが管理負荷が下がるかなと思って決断をすることにしました。
(諸々の設定をやってなくて未だにGoogleに引っかからないのは秘密)

 

投稿頻度、あげるよね?


Qiitaのストックもそれなりにあるし、GithubはTILというリポジトリに何かしらを投稿するようにしていますが、どっちつかずの内容は全部ここ(勉強会の感想とか)に書いていこうと思います。ポートフォリオ代わりにして転職のときに見せられるものになるのが当面の目標ですが、書きたいことをすぐに書いて反映させるを一番に再開しようと思います。

 

まあ、今は過去記事のインポートをせこせこやってます。マークダウンをインポートできないなんて聞いてないです。

 

qiita.com

github.com

AWSの基礎を学ぼう「Lightsail」の感想

Amazon Lightsailの概要

まずは公式から。

低価格の事前設定されたクラウドリソースを使用して、アプリケーションとウェブサイトを構築する

低価格かつEC2などを建てるよりも簡単に必要なものが提供されるサービスです。WordPressを建ててブログをさっさと書きたい、みたいな人に向いているサービスですね。
VPCAPI等の機能を提供してくれるので、ユーザー側が考えることが少ないのもいいですね。
Amazon Lightsail

料金について

ある程度機能が決まって提供されるため、予定外の出費というのが少ないと思います。価格のやすさについてはコンテナを例に述べられていました。 わかりやすいのと、ものによっては無料枠もあるので、他サービスよりも見積もりが立てやすいと料金表を見ていて思いました。
料金一覧

思っているよりも使えるテンプレート

使用可能なもの 改めてサイトを確認したのですが、「もうこれ使えば大抵はなんとかなるんじゃないんかな」と思っちゃいましたね。
使用している構成を見返して、Lightsailに置き換えられるのであればありなのでは。

NW設定について

当然と言えば当然なのですが、NWの細かい制御はEC2に劣ります。
Lambdaと同じように専用のVPCを使っているということもあって、要件が細かいものには不向きです。

Lightsailと他サービス

まずVPCについて。LightsailのVPCAWSのデフォルトのVPCにペアリングできるので、S3のプライベート通信が可能になります。
ただし、LightsailのNW帯域は通常のよりも細めに設定されており、通信速度を要求される場合は使わないほうがよいらしいです。
EC2もスナップショットを取ることができるため、Lightsailでは対応できなくなったものはEC2へと設定を移行できます。

まとめ:マネージドな部分が多く、サクッと作るのにいいサービス

自分で面倒な設定をすることなく立ち上げられるので、ハンズオンとかに使えそうですね。サクッとサービスを立ち上げて、更改の時期になったら移行するというやり方ができるのはいいなって思いました。

AWSの基礎を学ぼう「Wavelength」の感想

AWS Wavelengthの概要

まずは公式から。

AWS Wavelength は、モバイルエッジコンピューティングアプリケーション用に最適化された AWS インフラストラクチャです。
重要なのは事業対象がKDDI社のみであること。なので、スマホアプリのように色んな会社が使うようなものには大した意味をなさず、使い方は限定的になるとのこと。
AWS Wavelength

速度について

低遅延を目指すことを目的にしていますが、Outpostsと同様にAWSクラウドを母艦とするサービスです。
KDDIさんのページによれば「誤差は」2msほど(決して2msの通信の往復を可能にするというわけではないです)。
通常の通信は50msほどらしく、Wavelengthなら数msまで抑えられるとのことです。ただし、地域にもよるので場所によってはもうちょい遅延が発生するそうです。 低遅延を目的にする意味ではOutposts,Local Zonesと仲間ですね。
(余談ですが日本の国土の広さやインフラ設備を考えるとLocal Zonesは多分日本には来ないみたいですね)

Wavelength Zoneの場所

東京と大阪の2箇所にあるとのことですが、大阪RJにあるわけではなく、あくまで東京RJの一部が大阪にあるということらしいです。

Wavelength Zoneにデプロイするにあたって

AWSクラウドと異なり、リソースが潤沢にあるわけではないので、申込みが必要とのこと。昔はその後に厳し目の審査があったのですが、今はないみたいなので、一般人でも使えるみたいですね(必要なのかはべつにして・・・)

「あれこれに使うのに低遅延である必要があるから・・・」みたいなNWの要件ありきで使うサービスというのが特徴なので、「そうだ、Wavelengthを使おう」って話にはならないですね。

EC2等の価格は通常のサービスよりも高めに設定されているので、料金形態は注意が必要です。詳細は下記のリージョンで「アジアパシフィック(KDDI)」を選択すれば出てきます。
Amazon EC2 オンデマンド料金

Wavelengthの用途

  • VRゲーム等
    リアルタイムでの対戦のようなものに使えるとのこと。

そんなの身近にあるかなって思いましたが、某アニメに出てきたこれがまさにそうじゃないですか()

  • コンテンツ配信
    ライブ映像の配信とかは現状ではTwitterSNSの方がはやく結果を知ってしまうという事態になっていますが、現地の配信をWavelengthで取り込んでからインターネットに流すことで今よりも低遅延での配信ができるとのことです。

  • 機械学習
    AWSではGreengrassというサービスをすでにもっているのですが、それでは要件的に足りなさそうという用途とかだそうです。よりリアルタイムでの機械学習を使用するとかそういうことらしいです。

  • 自動運転
    曰く「夢」とのこと・・・。5Gはカバー範囲が狭く、KDDI社だけの現状では厳しいそうです。

まとめ:用途が限定されるけど

これから必要になってくるのと、日本中に広まらないと出来ないこともまだまだなんだなって理解しました。
まったく意味ないけど申請して使ってみようかな。

参考

AWS Wavelength 5Gデバイス向け・超低遅延アプリケーションプラットフォーム

AWSの基礎を学ぼう「Outposts」の感想

アウトプットをしよう

毎回亀田さんの勉強会では聞いてるだけになっていますが、せっかくだからアウトプットを再開していこうと思います。

Outpostsとは

ざっくりいうとデータセンターなどにAWSが用意したラックを直置きするというものです。これによって低レイテンシのアクセスができるようになります。
クラウドには向き不向きがあり、NWの遅延で困るようなもの(例では工場のシステムなどを上げていました)に対して効果を発揮します。
どなたがが「飛び地」と表現しておりましたね。

似たようなものとして(いとこ?)Wavelengthもありますが、それは次回とのこと。
AWS Outposts

ラックと中身・セキュリティについて

ラックは42Uラックという標準のものだそうですが、たしかに見たことあるものですね。
発注をするとAWSのチームがデータセンターに設置しにくるのですが、あくまでAWSの管理なので、顧客側では一切何も出来ないとのこと。
ただ顧客側は電源やNW,空調設備などデータセンターの準備に必要なものを用意する必要があります。聞き覚えがあるなあ

ハードウェアは改ざんできないようになっており、無理にこじ開けようとするとデータを壊すようにしているようです。バンクシーの絵みたいって感想でしたね()
クレジットカードでも採用されている「耐タンパー性」というものだそうです。

導入までの流れ

  1. 事前に構成を決めて発注
  2. AWSが配送と設置を行う
  3. ローカルでAWSリソースを起動し、実行

某県の〇〇運輸からみたいなこと言ってたのはどこだっけ・・・。ちょっと忘れました。
余談ですが、AWSの人間でもデータセンターの詳しい場所は不明だそうです。どっかにリークされてたけど

用途

ローカルでデータ処理を行う、オンプレのデータ等を含む低レイテンシでの処理を要求される場所で活躍するようです。
後述しますが、AWSクラウドにバックアップを取ることは必須要件です。

気をつけるべきこと

  • 構成はあらかじめ決めておく必要がある
    質問させてもらったのですが、HWの拡張も申請後にAWSの人間が来て作業をするということです。半オーダーメイドですが、クラウド特有のスケーラビリティはやはり難しいようです。
    ALBも使えますが、通常のALBはAZにまたがって使用することで耐障害性があがりますが、1つのサブネットでしか使用できないため、負荷分散のみでしか効果が期待できないです。
    他にもEC2のタイプは予め指定するなど、オンプレミスの導入にかなり近いという印象です。

  • AWSへのNW接続
    S3等耐久性が通常のものよりも落ちるため、AWSリージョンに対してバックアップは必須とのことです。そのためにはNWが引かれている必要があるのですが、通信やセキュリティを考えてもDirect Connectを使うのが良さそうです。というか他に使うケースはない気がします。
    Outpostsの設置場所は各データセンターの耐障害性に依存するので、場所によってはかなり不安なことになるなあと感じました。

  • エンタープライズサポート契約が必要
    Outpostsに異常があったときに担当者がアサインされて来るためにはエンタープライズ契約(24/365サポート)が必要とのこと。

まとめ:お近くにAWSを、とはいかなさそうですね

てっきりAWSの出張所みたいな感覚でいたのですが、思っているよりも用途は限定されることがわかりました。
Dynamo DB + Lambdaの構成は出来ないようですし、結局NWで接続しないとバックアップの保証はないです。
レイテンシを限界の限り低くするという用途がそもそもの目的なので、使用するケースは限られそうですが、逆に言えば他クラウドでは実現できないような低レイテンシを実現できるツールですね。
データセンターの業務を知っているだけに、身近じゃないのに身近に感じるサービスでした。

JAWS-UG 初心者支部37の感想

ちょっと緊張した司会

前回プッツンプッツンだったNWはとりあえずなんとかなり、画面のテストをしてみると「ノートの部分が表示されてる」とのこと・・・。 ワイドディスプレイでやると全画面表示にしてもこんなふうに映るんですね、初めて知りました。
colab一周忌のLTのときにノートが表示された理由が今やっと理解できました(別のディスプレイに表示させて終わらせましたが)

亀田さんのLT

前回もっと聞きたかったKTの続きということでスタートしました。AWSの中の人でも、サービスがパブリックになった時点で公開されるのはちょっと意外でした。 Lambdaがリリースされた時はその凄さがまだ浸透していなかったとのこと。今でこそサーバレスの代表と言ってもいいレベルですが、最初からもてはやされたわけではないんですねw
バッチ処理、という意味を再確認するという部分に皆さん反応しておりましたね。

Cloudfrontの課金形態はGB単位、しかも単位のbitとbyteが当時はごっちゃになっていたみたいで、見積もり時に8倍の値段で出してしまっていたとのこと。。。
当時の計算エクセルシートがお土産に配られました。

SAAの勉強でしか聞かなかったインスタンスストアですが、使いやすくなったそうなので、是非使ってほしいとのことでした(SAAの試験に関する部分ももにょもにょと言ってましたw)

織田さんのハンズオン

Code 〇〇シリーズを触るどころか、初めて名前を聞くものもありました。Pipelineは知ってますが、他はナニソレ状態です。 前半はCodestarによる構築、後半は手動で全部やるという2段階の内容でした。

Codestar,すごいですね。。。インスタンスどころか、S3やIAMのアクセス権等などを待っているだけで全部作り上げてくれるんですか。
Cloudformationよりも多くのことができそうだなと感じました。

この手順書は同じく初心者支部の武田さんがJAWS DAYSで使っていたclaatを使用しておりました。
これ便利ですね。

興味のあるサービスで食いついてくれた人も?

JAWSの勉強会では好きなAWSサービスを紹介するのが常?ですが、今回は興味のあるサービスということでAWS Systems Managerをあげさせていただきました。
Incident Manageという運用が好きそうなサービスがリリースされていましたので。

こんなのをつぶやいたら執筆者ご本人からリプがくるとは夢にも思っておりませんでしたが・・・。
ちなみにITILに完全準拠しているわけではないのですが、対応できるとのことです。

まとめ:ハンズオンは自身も勉強になるからいいですね

触ったことがないシリーズをまとめて触るきっかけはなかなかないので、今回のハンズオンが自身がすごく勉強になりました。
ハンズオンは作ると結構ちゃんと勉強しないといけなくなるので、やってみたほうがいいという話になっていました。

JAWS-UG 初心者支部のLTの補足記事:HoneycodeとAppFlowの可能性

接続が悪くて正直ドッキドキだったあの日

接続がプッツンプッツンで実は緊張していたのはそんな理由でした。
2回ほど接続きれてそれどころじゃなくてギリギリに復帰できたのでもう緊張がやばかったです。
おいこらWiMAX...

ちょっとした前提

ServiceNowを触るという前提があるので、どうしても判断基準がそこになってしまうので、ご了承ください。

改めてHoneycodeを触った時の感想とか

さて、今回のLT用に触ったのは資産管理を行うテンプレートを使用しました。 会社の端末の資産管理をエクセルとかで行わなくてもいいようにという目的があります。
実際にテンプレでしか軽く触っていないのですが、シートに項目を追加していけば細かく管理ができるということがわかりました。

LTでも話しましたが、SaaS側の用意するポータルサイトを下手にいじくって面倒なことになるよりも、フルマネージドなHoneycode側でUIをいじるほうが安全です。
顧客でも結構カスタマイズを要求されそうな場面でもこれならいける、と思っちゃいました。

AppFlowを初めて知って

実は今回始めて知ったサービスです。SaaSAWSのサービスをつなげるということをそもそも念頭においていなかったです。
(ServiceNow内で解決するという感じだった)

さて、本格的に触っていないのですが、今回はマッピングを適当に振ったので、シートへの連携があまりきれいになっていなかったです。
というのも、そこまでするのが今回の目的じゃないのは触っている途中で気づきました。。。

実は本当に見たかったのはどこまでの連携が可能なのかということです。見てみるとお目当てのログファイルをS3に入れられることが判明しました。
このServiceNow内でもログは保管できるのですが、一定期間以上にするのはよくないらしく、外部に保存先を求めていたんです。
AppFlowで直接つなげてしまえばログを長期間保管できますし、いわゆるベストプラクティスを守ることができる、というのはありがたい話です。

AppFlowがもたらしてくれるメリット

ServiceNowでは外部ツールとの連携にMIDサーバーという別途サーバーを建てる必要があるのですが、これがまた面倒なもので。。。
単純にメンテ対象が増えるのと、連携のために色々設定を盛り込んであげるのがよくないなって思っていました。

でもAppFlowならテーブルとカラムの連携だけしてあげれば勝手にやってくれます。もちろんすべてをカバーしてるわけではないのですが、十分代替の候補になりえます。
あとは、機械学習の外部ツールとの連携の必要がなくなる、というのが大きいです。(これはライセンス料とかの話も出てくるのですが・・・)

例えば大量のインシデントをさばき、一時的に出るものを解析してそれを監視の検知条件から外すということをやりたい場合を考えましょう。
ServiceNowで持っている情報をAppFlow経由でS3にすべて保管させると、S3へのアップロードをトリガーにGlueやRedshift、QuickSightを使うということが出来ますよね。 これらも当然フルマネージドで、QuickSightなんかはさっと試すことができますよね。加えて料金もこっちのほうが抑えられそうという試算さえ生まれました・・・。

あとはデータを取り込む際にマスキングをかけられるというのもGoodです。うちの顧客的に。
下手にカスタマイズや内製化で苦しむことがなくなるのではないかという妄想がかなりはかどりました。

まとめ:LTがもう少し長かったら良かったかも

今回はあまり触れることのないHoneycodeを紹介するのが目的なので、かなり初心者よりな内容になりました。
実際はもっといろんなことが可能になる、運用で辛い部分をほぼ全てローコードでフルマネージドにできるのではないかということを伝えたかったです。

最初は「Honeycode完全に理解した」みたいにしようとしていたのですが、上記のような妄想が広がってタイトルを変更しました。
Salesforceやkintoneを使っている人達ともこういう観点で話をしてみたいですね。
あ、タイトルは某アニメのオマージュです・・・。

AWS 東京リージョンの被った直近の障害をまとめてみた

実はちょくちょく出てる障害

AWSのマネジメントコンソールから「Personal Health Dashboard」と検索するとこれまでのイベントが出力されます
Personal Health Dashboard

直近の1ヶ月しか見れませんが、表立って出ていないものだとStorage Gatewa VMにて、キャッシュやアップロードなどが出来ない事象が発生していました。
ただ、Storage Gatewayはオンプレとクラウドを接続するためのツールですので、直接関係のない人は多かったと思います。
Storage Gateway

公式で確認する方法もありますので、とりあえずなにか怪しかったらこちらを確認するのが良いですね。
ステータスの確認

1週間しかみれないので不便だなあと思っていたら便利な方法も見つけました。
【小ネタ】AWSで過去に発生した障害の履歴を確認する方法

2019/08/23 空調設備の故障でAPNE1-az4のEC2関係が軒並み死亡

単一AZ(ap-northeast-1a)で冷却装置が故障したことでオーバーヒートを起こし、EC2とEBSの一部が死亡。
それに伴って、関係サービスであるRDS、Redshift、 ElastiCache および Workspace等も道連れという、東京リージョンでは今の所最大の障害かと思います。
東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要
被害者:結構なゲーム会社とか(多すぎるので・・)

2020/04/20 レイテンシの増加により、通知系等がお亡くなりに

エラーレートの上昇などの複数の要因でCloudWatch、Simple Queue Service、CloudFormation、Lambdaが駄目に。AZ単位じゃないサービスが被害を被ると流石にどうにもなりませんね。 https://xtech.nikkei.com/atcl/nxt/news/18/07639/

2020/09/26 CFの断続的なエラーにより、一瞬途絶える

CloudFrontのエッジロケーションが障害を一時的におこし、ちょっと話題になりましたね。
だいぶ早く解決したので誤報説もでましたが、「またかよ」みたいな声はありましたね。
https://dev.classmethod.jp/articles/cloudfront-fault-20200926/

2020/10/22 ネットワークの接続不良でAPNE1-az2のEC2とEBSのパフォーマンスが低下

今日(執筆時点)に起きた出来事ですね。AZ(ap-northeast-1d)のネットワーク接続が不調に陥り、EC2とEBSの一部でパフォーマンスが低下し、アクセスができなくなりました。
前回の障害よりは軽いですが、それでもPayPayがお昼時に死んだので、財布を持たなかった人は危なかったのかもしれません。
被害者:PayPay、メイプルストーリー

どうすればいいのか

AZの単一構成をなるべく避けるのが一番簡単なのですが、速度重視にするためには出来ない構成なので、Active-Stanbyの構成をとっておくのがいい気がします。(無駄な出費がかかりますが・・・)

ここ最近増えたなという声もあるので、せっかくですしメディアに出たものを調べてみましたが、2020年はちょっと多いですね。