AWSのOpenSearchでソフトウェアアップデートをしたら、JVMメモリプレッシャーが荒ぶった件について

こんにちは。 エキサイト株式会社の三浦です。

AWS OpenSearch Serviceではたまにソフトウェアアップデートが来ることがありますが、「バージョン自体をアップデートするわけではないからそこまで大きな変化はない」と考えていると、驚くような事態が起きることがあります。

今回は、ソフトウェアアップデートを行った結果、JVMメモリプレッシャーが突如荒ぶりだした件について説明します。

AWS OpenSearch Serviceとは

AWS OpenSearch Serviceは、AWSが提供するマネージドなOpenSearchのサービスであり、ログや文章など様々なデータを保存・分析したり、検索したりすることができます。

aws.amazon.com

Amazon OpenSearch Service を使用すると、インタラクティブなログ分析、リアルタイムのアプリケーションモニタリング、ウェブサイト検索などを簡単に実行できます。

例えば様々な文章データを入れたOpenSearchに対してキーワードを投げると、設定にもよりますが、単純にキーワードが完全一致したデータだけでなく、形態素解析等を行った上で一致度が高いデータを返してくれたりします。

非常に強力なアプリケーションな上、AWSがマネージングしてくれているために使用するエンジニア側ではやりたいことに注力ができるのですが、たまにその「マネージド」な部分に落とし穴があることもあります。

ソフトウェアアップデートを行ったらJVMメモリプレッシャーが荒ぶった

現在私のサービスでは、OpenSearchを「Elasticsearch 7.10」のバージョンで運用しています。

最近久々にOpenSearchに手を加える作業があり、ついでということでソフトウェアアップデートを行いました。

実際に行ったのはソフトウェアアップデートだけなのですが、その結果JVMメモリプレッシャーのメトリクスが以下のようになりました。

明らかにJVMメモリプレッシャーが今までと異なる動きをしています。

幸いOpenSearchの挙動自体は問題なかったので、一旦様子を見ながら色々と調べていたところ、以下のブログを教えていただきました。

aws.amazon.com

In the latest service software release of Amazon OpenSearch Service, we’ve changed the behavior of the JVMMemoryPressure metric.

この記事によると、どうやら最新パッチを当てるとJVMメモリプレッシャーのメトリクスの計測方法が変わるため、内容が変わることがあるようです。

より正確に異常を検知するための仕様変更とのことで、どうやら挙動そのものには影響はなさそうです。

最後に

何の気無しにソフトウェアアップデートを行うと、今回のように想定外のことが起きることがあります。

今回のように見た目上で大きな変化がある場合もあるので、こういった場合でも焦らずに色々と調べて見るようにするのが良さそうです。

「外部勉強会 リビルドへの道」に登壇しました!!〜アプリ編〜

エキサイト株式会社でモバイルアプリ開発に携わっている奥田です。 社外に向けてアプリで実施しているリビルドへの対応について発表しました。

概要

詳細は下記のconnpassに記載されています!

excite.connpass.com

発表内容

リビルドのために必要なものとして4点について重点的にお話しました。

  1. 技術選定

  2. コミュニケーション

  3. 技術交流

  4. 気合い

詳しくは下記の資料に掲載しています!

www.slideshare.net

発表の様子

発表中はみなさんコメントをしていただき大変楽しく発表できました! 質疑応答もたくさんいただき社外の方と交流できてよかったです。

懇親会

発表後の懇親会で技術的な交流ができました。デザインや更に詳しい実装についての交流ができ、とても楽しい時間でした。今後も登壇終了後に懇親会を開催しますので興味のある方はぜひ参加していただきたいです!

最後に

エキサイトではフロントエンジニア、バックエンドエンジニア、アプリエンジニアを随時募集しております。長期インターンも歓迎していますので、興味があれば連絡いただければと思います。今回の記事を読んで少しでも興味が湧きましたら是非応募お願い致します!!

就業型インターンの募集情報です! www.wantedly.com

募集職種一覧はこちらになります!カジュアル面談からでも構いません。 www.wantedly.com

「外部勉強会 リビルドへの道」で「実際にリビルドを完遂してみて」を発表しました!

こんにちは。 エキサイト株式会社の三浦です。

2022年6月27日、エキサイト主催で行った「外部勉強会 リビルドへの道」にて発表させていただきました!

今回は、簡単に振り返りたいと思います。

「外部勉強会 リビルドへの道」とは

「外部勉強会 リビルドへの道」は、リビルドに関連する勉強会です。

excite.connpass.com

今回の勉強会では、リビルドに挑戦していること、リビルドを完遂させたことについてお話します!

今回は計3名が発表しました。

自身の発表内容

今回私は、実際にリビルドを完遂した経験について発表させていただきました。

speakerdeck.com

  • リビルドの目的
  • リビルド内容
  • リビルドによる効果予測
  • 実際にリビルドを行ったことによる効果
  • 大変だったこと
  • リビルドの効果をより長持ちさせていくには

というアジェンダで発表しています。 良ければ見ていただけると幸いです。

最後に

会社でこういった発表の機会があると、改めて自分がやってきたことを振り返ることができてちょうど良いです。

また機会があれば参加しようと思います。

AWS移行におけるcloud-initを使ったLinuxの初期設定

エキサイト株式会社の武藤です。

オンプレにあるサーバをAWSへ移行する際に、AWS Application Migration Service (AWS MGN)を使いました。 その際に、オンプレ特有のサーバの設定もそのまま引き継がれるため、修正すべき箇所がいくつか出てきます。

EC2には起動時に実行したい処理をシェルスクリプト、cloud-initから設定できるユーザデータという機能があります。 今回はcloud-initを使った設定変更を行ったので紹介します。

docs.aws.amazon.com

cloud-init とは

Linux OSの初期設定を行うためのツールです。公開鍵の設定、ユーザ作成等をyamlで記述できます。 元々はEC2用に開発されたツールのようです。Ubuntu 18からはプリインストールされています。

cloud-init.io

cloudinit.readthedocs.io

利用例

利用例について紹介します。

前提として、担当したシステムのインフラ構成の管理にTerraformを採用しております。 移行したサーバを管理するため、MGNで移行したインスタンスをAMIにした上で、 Terraformでは、そのAMIを基にしたEC2の構築と、設定したいユーザデータをコードに残しています。

ネットワーク周りの設定

ホスト名やDNS周りの設定です。

#cloud-config
hostname: sample-host
fqdn: sample-host.net
manage_etc_hosts: true
manage_resolv_conf: true
resolv_conf:
  nameservers:
    - x.x.x.x
  searchdomains:
    - ap-northeast-1.compute.internal
  domain: ap-northeast-1.compute.internal

オンプレからホスト名の命名を変更したため、設定し直しました。 また、resolv.confに社内DNSが設定されていたため、AWS用に変更しました。

apache confの設定

apacheのVirtualHost等の設定です。

#cloud-config
write_files:
- path: /etc/apache2/sites-available/sample.com
  content: |
    <VirtualHost *:80>
      ServerName    sample.com
      DocumentRoot  /var/www/html/index.html
    </VirtualHost>
  owner: 'root:root'
  permissions: '644'

write_filesモジュールでは任意のテキストをファイルに書き出せます。 複雑なVitrualHostはこちらで設定しました。 パーミッション等も設定できます。

細かい設定はシェルスクリプト

runcmd モジュールでシェルスクリプトも実行できます。

#cloud-config
runcmd:
- a2ensite sample.com
- service apache2 restart

runcmdでだいたいは事足りてしまいますが、yamlで書かれた設定は構造化されているので見やすさもあります。

これ以外にもにモジュールが多く用意されています。

cloudinit.readthedocs.io

cloud-initのキャッシュ削除

Ubuntu18のサーバを移行するときにハマった問題があるので紹介します。

先述したようにUbuntu18からcloud-initがプリインストールされており、通常のセットアップ用途にも使われます。ただ、 一度cloud-initを実行したサーバの場合、新たに用意したユーザデータが渡らず、うまく動作しないようです。

今回は、オンプレ環境時代の構築時にcloud-initが実行されており、それをMGNで移行したEC2のAMIに対して新たにユーザデータを設定し、起動するというケースだったため、想定通りに作動しませんでした。

原因としては、一度cloud-initを実行したサーバでは、以前の設定がキャッシュとして残り続けてしまい、新しいユーザデータを参照できていないことでした。

cloud-initでは、ユーザデータを読み込むソース(datasource)の設定があり、様々なクラウドサービスに対応しています。

cloudinit.readthedocs.io

/var/log/cloud-init.log にdatasource決定までのログが出力されます。 今回はログからNoCloud が指定されていることがわかり、オンプレ環境時代の キャッシュが使われている事がわかりました。

そこで、キャッシュを削除するために、cloud-initのcleanコマンドで設定をクリーンアップしました。

cloud-init clean

クリーンアップした状態をAMIにし、EC2を起動したところ、意図した設定が実行されました。 再びログを確認すると、datasourceが Ec2 になっていました。

この問題に直面したときに気づきましたが、CLIインターフェースがあります。

ドキュメントはこちらです。 cloudinit.readthedocs.io

まとめ

cloud-initを使ったLinuxの初期設定について紹介しました。 軽微かつ初回起動時に設定したい内容であれば、十分な機能だと思います。

今回はAWS移行に際したオンプレ特有の設定の整理を目的にcloud-initを使いましたが、継続的な構成管理をするのであれば、ansibleやchef、AWSマネージドのOpsWorksなどが適していそうです。 用途や要件にあった方法を採用してもらえればと思います。

参考資料

dev.classmethod.jp

qiita.com

qiita.com

Mac版!TAURIを使って、デスクトップアプリを作ってみる

いつものtaanatsuです。
今日は、Electronの代替(に、なるであろう)Rust製の
クロスプラットフォームデスクトップアプリケーション作成フレームワーク 「TAURI」で遊んでみましょう。

Electronに変わる、つまり、HTML/CSS/JavaScriptでUIを組めるということです!
さらにさらに、TAURIはChromiumを使わずOSが備えているWebViewの機能を用いるため、吐き出されるファイルも軽量になるようです!
胸熱ですね!!

そして今回、Windows版の記事はあったので、それを見ながらMacでやっていきます。
それではやっていきましょうか。

事前準備

Rust製ということで、RustをPCに入れておかないといけません。
Windows版の記事には「Scoopで入れるとコンパイル時にエラーになる」とのことでしたが、
MacだとBrewで入れていても動くっぽい(動作した)ので、それでやっていきます。

$ brew install rust

TAURIのプロジェクトを作成

フロントエンドあまり書かないマンのわたしは、最近の流行りを知らないので手癖でyarnを使っていきます。
もちろんnpmでも実行できますのでご安心ください。yarnをnpmに置き換えるだけのはずです。

まずは以下のコマンドを実行し、対話形式でtauriのプロジェクトを作成します。

$ yarn create tauri-app

## 好きなキーをおしてください
Press any key to continue...   

## 好きなアプリ名を入れてください。デフォルトは「tauri-app」になります
? What is your app name?

## タイトルバーに表示したい文字列を入力してください。デフォルトは「Tauri App」になります。
? What should the window title be?

## JSに何を使うかを聞かれます。好きなものを選んでください。今回はVanilla.jsを選択しております。
? What UI recipe would you like to add? Vanilla.js (html, css, and js without the bundlers)
❯ Vanilla.js (html, css, and js without the bundlers) 
  create-vite (vanilla, vue, react, svelte, preact, lit) (https://vitejs.dev/guide/#scaffolding-your-first-vite-project) 
  create-react-app (https://create-react-app.dev/) 
  Svelte (https://github.com/sveltejs/template) 
  Solid (https://github.com/solidjs/templates) 
  Vue CLI (https://cli.vuejs.org/) 
  Angular CLI (https://angular.io/cli) 
(Move up and down to reveal more choices)

暫く待つとプロジェクトが作成されます。
その際、以下のような指示があるので表示される3つのコマンドを実行してみましょう。

>> Running final command(s)

    Your installation completed.

    $ cd tauri-app
    $ yarn install
    $ yarn tauri dev

こんにちは世界!

UIを準備する

さて、サンプルは動作したので自分でUIを作っていきたいですね。

デフォルトの設定を破棄する

新しくプロジェクトを作ってもいいですが、面倒なので使いまわしていきます。
設定を書き換える必要があるので、自動で作成されているsrc-tauriディレクトリを削除します。

$ rm -rf src-tauri

それか後述するinit時に、--forceをつけると消さなくても良いかもしれません。(試してない)

UIディレクトリの作成

UIデータを保存するディレクトリを作成します。

$ mkdir ui

UI用のHTMLを作成

作成したuiディレクトリの中に、index.htmlファイルを以下の内容で作成します。
あ、ここですでにいろいろ試したい方は好きに書き換えてください。
ひとまずコピペで遊びたいって人向けに貼っておきます。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
またあったね世界!
</body>
</html>

TAURIの設定ファイルを作成

以下コマンドを実行し、TAURI用の設定を作成します。
設定は対話形式で行われます。

$ yarn tauri init 

## 好きなアプリ名を入れてください。デフォルトは「tauri-app」になります
✔ What is your app name?

## 好きなアプリ名を入れてください。デフォルトは「tauri-app」になります
✔ What should the window title be?

## UIアセット(HTML/CSS/JS)がどこにあるかを指定します。
## ここで注意が必要なのは、`プロジェクトディレクトリ/src-tauri`が基準になります。
## 作ったuiディレクトリはsrc-tauriディレクトリの一個上の階層になるので「../ui」と入力します。
✔ Where are your web assets (HTML/CSS/JS) located, relative to the "<current dir>/src-tauri/tauri.conf.json" file that will be created?  ../ui

## この子も今回はuiディレクトリが基準なので`../ui`と入力します。
✔ What is the url of your dev server?   ../ui

実行!

以下コマンドを実行します。

$ yarn tauri dev

またあったね世界!

終わりに

いかがだったでしょうか?
ひとまずベースを整えてみました。
次はホットリロードなんかを書いていこうかなーと思っています!

それでは、また、次回!

参考

よく使うサーバのファイル容量便利コマンド

どうも、taanatsuです。
今回はよく使うサーバのファイルをチェックするコマンドをまとめます。
サーバで「ん?」ってなったときにサクッと使えるコマンドたちです。

それではやっていきましょうか。

ディスク容量をわかりやすく表示

サーバ全体の容量を表示してくれます。 -hで人間様のわかりやすい単位で表示してくれます。

$ df -h

ファイルの容量を一覧で表示

サーバの圧迫の原因を探るときに使います。

$ du -sh フォルダパス

$ du -sh /var/*

$ du -sh /var/にすると/var/ディレクトリの容量だけが表示されます

ファイルの容量を大きい順に10件表示

ちょっと組み合わせです。

$ du -sh ファイルパス | sort -hr | head -10

du -sh /var/* | sort -hr | head -10

ファイル容量の大きい順に一覧表示

$ ls -lSh ファイルパス

$ ls -lSh /var/

lessなどと組み合わせると見やすくなります

10分以内に更新されたファイルを2秒ごとに監視し続ける

$ watch find /ファイルパス -mmin -10

$ watch find /var/ -mmin -10

その他、「10分以内にアクセスされた」だと-aminを使います。

$ watch find /var/ -amin -10

複数のIntelliJのプロジェクトをタブにまとめるちょっとしたTips

エキサイト株式会社エンジニアの佐々木です。立場上、複数のプロジェクトをIntelliJで立ち上げることが多く、Windowがバラバラになってしまい使いにくかったんで、技術ブログに書くほどではない小さなTipsですが、調べてもあんまりでてこなかったのでメモ程度で書いておきます。

結論

下記のように複数プロジェクトが上のタブにまとまります。(タブから分離できます。分離したあとは戻せません)

赤タブ: プロジェクト 青タブ: プロジェクト内のファイル

前提

  • Mac限定 ※ WindowsLinuxでのやり方はあるかもしれないですが、調査していないです

設定方法

これはIntelliJの設定ではなく、Mac側の設定を行います。

左上のリンゴマーク -> 一般 -> 書類を開くときはタブで開く常に にします。

この設定をしたあとにプロジェクトを立ち上げると、このような状態になります。

やってみて

IntelliJのプロジェクトがまとまって大変お世話になっております。エキサイト佐々木です。スッキリしました。複数プロジェクトがバラバラならないので非常に使いやすいです。

最後に

エキサイトではフロントエンジニア、バックエンドエンジニア、アプリエンジニアを随時募集しております。長期インターンも歓迎していますので、興味があれば連絡いただければと思います。

カジュアル面談はこちらになります! meety.net

募集職種一覧はこちらになります!(カジュアルからもOK) www.wantedly.com

第1回 テクデザBeer Bashを開催しました

こんにちは、エキサイトでエンジニアをしている吉川です。 先日6/10(金)に弊社エンジニア・デザイナーの交流会として「テクデザBeer Bash」を開催したので、そのレポートを運営視点で書いていこうと思います。

Beer Bashとは

「Beer Bash(ビアバッシュ)」とは、ビールなどのお酒や軽食を片手に行う社内ミーティングのことを言います。beer(ビール)+ bash(にぎやかなパーティーどんちゃん騒ぎ)を合わせた造語で、真面目な部分を残しつつ、社員同士がカジュアルな雰囲気で交流を行うことが目的です。発祥はシリコンバレーのとあるIT企業で、社内エンジニアの士気を高めるために始まりました。

テクデザBeer Bash開催へ向けて

弊社では各事業部内での交流は活発に行われているのですが、事業部を超えた交流は比較的控えめになっていました。これを解消するべく、普段の業務で関わらない方々との接点づくりを目的としてイベントを開催する運びになりました。

イベント案は何個かあったのですが、その中でもカジュアルな雰囲気があること、オフライン交流ができること、継続的に開催しやすいことが決め手となり、Beer Bashを開催することに決まりました。

また6月初頭は2022年度新卒技術研修が終わる時期なので、第1回は新卒の方々と社員の接点を作ることを運営の目標にしました。

※ちなみにオンラインでの交流事例は以下の過去記事をどうぞ! tech.excite.co.jp tech.excite.co.jp

当日の様子

ここからは写真を使いながら当日の様子をお伝えしていきます!(感染防止対策を徹底し開催しました、また一部情報保護のためマスキングしています)

開催場所は弊社カフェスペース。軽食のメインはピザとたこ焼きで、あとはコンビニのおつまみを適量購入しました。またお酒はオフィス近所に酒屋があるので、そちらで購入しました(この辺は何かあってもアドリブでなんとかしやすいので、運営的には立地に感謝です笑)。

19時前に乾杯!! 今回はメインコンテンツとして、下記の3つを発表していただきました!

新卒エンジニアから自己紹介LT

最初は新卒エンジニア3名の自己紹介です!研修→正式配属から数日経ってどんなことを思ったのか、これからどんなエンジニアを目指すのか語ってもらいました。また研修を担当したメンターからも他己紹介として人となりを紹介しました。

デザイナーからCanvaでのバナートレースライブ

続いてデザイナーから、弊社で導入しているツール「Canva」を使ってプレゼンを行いました!Canvaでどんなことができるのか?プレゼン冒頭の見本を実際にどうやって作るのか?をPC作業担当と解説担当の2人タッグで発表しました。ここはエンジニアとデザイナーをうまく交流させることができたコンテンツだったかと思います。

アプリエンジニアからFlutterのライブコーディング

最後にアプリエンジニアから、弊社アプリ開発の一部で採用している「Flutter」のライブコーディングを行いました!こちらもPC作業担当担当と解説担当の2人タッグで発表し、TODOアプリをその場で開発することで、アプリ開発以外のエンジニア・デザイナーに実装イメージを掴んでもらいました。質疑応答も盛んに行われ、オフライン発表はオンラインに比べて質疑応答が柔軟にしやすかったのが印象的でした。

最後はフリートークの時間となり、21時ごろに解散となりました。各コンテンツ大変盛り上がったまま終了することができました!

今回のメインコンテンツは個別記事もございますので、詳しく知りたい方は以下からどうぞ!

tech.excite.co.jp tech.excite.co.jp

またWantedlyにもイベントレポートがございますので、よければ合わせてご覧ください! www.wantedly.com

開催した結果と今後について

オフラインの社内イベントは久々だったのですが、無事成功させることができました。開催後行ったアンケートについても、85%の参加者が普段の業務で関わらない方と話せたと回答し、また新卒エンジニアからも先輩社員と話しやすい雰囲気が作れたと回答されました。全体的に大好評だったイベントとなったと思います。

Beer Bashは今後も継続的に開催していく予定です!現在は隔月開催を目指して運営チームは再び走り出しています。また第2回以降がありましたらテックブログにて紹介させていただきます!

最後になりますが、弊社ではエンジニア、デザイナーの募集を随時行っています。もしご興味があれば以下からご連絡ください!! www.wantedly.com

Flutter勉強会を開催しています!

エキサイト株式会社でモバイルアプリ開発に携わっている奥田です。 本日はアプリエンジニアの有志が集まり、Flutterの知見を深めるため開催している勉強会について執筆していきます。

開催の経緯は?

部署間を跨いだ交流が希薄だったため、知見交換の機会がありませんでした。そんな社内の現状からアプリエンジニアのメンバーが交流を活性化し、知見交換をすることで技術力を向上させたいという意見がキッカケで開催されました。

活動概要

  • 部署間での技術交流
  • 最新技術のキャッチアップ
  • 設計周りの相談会

上記の交流が主となっています。勉強会を開催して技術交流が活性化し、Flutterとどのように向き合うのか意識が統一できてきたと感じています。コミュニケーションを持てる場を創出することができたのが1番のメリットだと感じています。

活動内容

  • flutterを3.0.0系の変更点と対応項目について
  • freezedを2.0.0系の変更点と対応項目について
  • 推奨ライブラリの選定
  • OSごとのローカルストレージの挙動について
  • UseCaseを使用した際のメリット、デメリットについて
  • RiverpodのProviderごとの使用の勘所の共有
  • Riverpodを採用した設計についての議論

現時点で上記のことを議論してきました。アップデート関連では問題点の共有ができ、スムーズに実装に落とし込むことができました。技術交流をすることで実装の落とし穴、アップデート変更点の共有ができたのはいい傾向だと感じています。さらにRiverpodに対する知見の共有、設計への落とし込みかたの議論ができたことは効果的な使用方法、最適な設計を実現する第一歩だと感じています。

今後について

今後は勉強会の内容を社外にも定期的に発信していきたいと思います。読者のみなさんと一緒にFlutter界隈を盛り上げていければ大変嬉しいです。

最後に

エキサイトではフロントエンジニア、バックエンドエンジニア、アプリエンジニアを随時募集しております。長期インターンも歓迎していますので、興味があれば連絡いただければと思います。今回の記事を読んで少しでも興味が湧きましたら是非応募お願い致します!!

就業型インターンの募集情報です! www.wantedly.com

募集職種一覧はこちらになります!カジュアル面談からでも構いません。 www.wantedly.com

プライベートサブネットにあるサーバ上の開発環境Webページにアクセスする方法

こんにちは。 エキサイト株式会社の三浦です。

AWSで開発を行う場合、多くのアプリケーション用サーバはプライベートサブネットに設置することになるでしょう。 つまり、もしWebアプリケーションの開発環境がサーバ上に存在する場合、本来インターネットからアクセスできないプライベートサブネットにあるサーバに、何かしらの方法でアクセスする必要があるということです。

今回は、そのための方法を紹介します。

プライベートサブネット

プライベートサブネットは、以前以下の記事でも紹介しましたが、インターネットから直接アクセスできない場所となっています。

tech.excite.co.jp

そのため、もしプライベートサブネットにあるサーバの開発環境のWebページにブラウザ等からURLでアクセスしたい場合、何かしらの手段を講じる必要があります。

プライベートサブネット上のサーバの開発環境にアクセスする方法

今回はプライベートサブネット上の開発環境にアクセスする方法として、

  1. ALBを使う方法
  2. 踏み台サーバと /etc/hosts を兼用する方法
  3. 踏み台サーバと nip.io を兼用する方法

の3つを紹介します。

ALBを使う方法

AWS上でWebアプリケーションを作っているなら多くの方が本番環境ではALBを使っていると思いますが、これを開発環境でも使うようにすれば、インターネット経由で開発環境にアクセスできるようになります。

この場合は、ALB自体がパブリックサブネットに作られているのでALBにはインターネットからアクセスでき、そのALBがプライベートサブネット上のサーバと通信するため、結果的にインターネットからWebページが見られる、という構図です。

ただしこの場合、URLをどうするかという問題があります。

開発環境のURLでは taro.sample.co.jp のように、開発者のユーザ名をURLに含めることで、開発者ごとに異なるディレクトリを見るようにする場合があると思います。 これを実現するため、ローカルPCの /etc/hosts を使う場合が多いのではないでしょうか。

/etc/hosts では、IPアドレスとURLを指定することで、そのPCで使用する場合に限り、指定したIPアドレスとURLを紐付ける事ができます。

例えば、

10.0.0.0 taro.sample.co.jp

とすれば、 taro.sample.co.jp にアクセスした時に、自動的に 10.0.0.0 というIPアドレスにアクセスしてくれる、といった具合です。

ただしALBを使っている場合はこれには問題があります。

ALBのIPアドレス不定期に変わる可能性があるため、上記の方法で指定していると、ALBのIPアドレスが変更されるたびに /etc/hosts を変える必要があるのです。

そのため、もしALB経由で開発環境にアクセスしたいのであれば、 /etc/hosts を使うのではなく、開発環境のURLを Route53 パブリックホストゾーンに登録するのがいいかと思われます。

Route53 のパブリックホストゾーンに登録する場合、ALBであればALBそのものをURLのアクセス先として紐付けることができるため、ALBのIPアドレスが変わっても気にする必要がありません。

ただしこの方法を取る場合、パブリックなURLとして開発環境のURLが登録されるということになります。

まとめると以下のようになります。

ALBを使う方法とは

パブリックサブネットにあるALBからプライベートサブネットにあるサーバを見るようにし、ブラウザ等からはそのALBに対してアクセスするようにする。

ALBにアクセスするために、Route53のパブリックホストゾーンに開発環境のURLを登録し、ALBと紐付けておく。

利点

本番環境がALBを使用しているなら、それと同じ設定で開発環境にアクセスできる

欠点

  • 開発環境のURLをパブリックなURLとして登録する必要があり、セキュリティ的な心配が残る
  • 開発環境用のパブリックホストゾーン管理が必要になる
  • 場合によっては、開発環境用のURLのためにALBのリスナールールが複雑化する可能性がある

踏み台サーバと /etc/hosts を兼用する方法

2つ目は、踏み台サーバと /etc/hosts を兼用する方法です。

これは簡単に言えば、1つ目のALBを使う方法について、ALBの代わりに踏み台サーバを使うという方法です。

踏み台サーバとは、文字通り「踏み台」に使うサーバです。 このサーバはパブリックサブネットに作っておき、例えばプライベートサブネットに存在するサーバにSSHログインしたい時や、プライベートサブネットに作ったDBに接続したいときなどに使用します。

今回はその踏み台サーバに、例えばNginxを入れて指定のURLが来たら指定のサーバにアクセスを流すようにします。 具体的には、 taro.sample.co.jp というURLが来たら、 10.0.0.0IPアドレスのサーバに流す、といった具合です。

server {
    listen 80;

    server_name taro.sample.co.jp;

    location / {
        proxy_pass http://10.0.0.0;
    }
}

そして、 taro.sample.co.jp で踏み台サーバにアクセスが行くように、踏み台サーバのIPアドレス/etc/hosts を使ってURLと紐付けます。 踏み台サーバのIPアドレス99.0.0.0 であれば、

99.0.0.0 taro.sample.co.jp

といった形です。 これで、 taro.sample.co.jp にアクセスすれば、踏み台サーバを経由してプライベートサブネットに存在するサーバにアクセスすることができるようになります。

まとめると、以下のようになります。

踏み台サーバと /etc/hosts を兼用する方法とは

パブリックサブネットにある踏み台サーバからプライベートサブネットにあるサーバを見るようにし、ブラウザ等からはその踏み台サーバに対してアクセスするようにする。

踏み台サーバからプライベートサブネットにあるサーバを見られるようにするために、Nginx等でアクセスを流すようにする、

また、踏み台サーバにアクセスするために、/etc/hosts で指定のURLと踏み台サーバのIPアドレスを紐付けておく。

利点

踏み台サーバがあれば、それだけで開発環境にアクセスできる

欠点

  • 踏み台サーバにNginx等の設定が必要になる
  • /etc/hosts の管理が必要になる

踏み台サーバと nip.io を兼用する方法

3つ目は、踏み台サーバと nip.io を兼用する方法です。

nip.io とは、URLだけで向き先IPアドレスを指定してアクセスしてくれるサービスになります。

nip.io

Dead simple wildcard DNS for any IP Address

公式にも書いてあるとおり、例えば 10.0.0.1.nip.io というURLでアクセスした場合、IPアドレス 10.0.0.1 に対してアクセスできるようになります。

これを使用すると、色々と便利になります。

例えば今回の場合、踏み台サーバを使うところまでは同じですが、URLと踏み台サーバのIPアドレスを紐付ける時に、 /etc/hosts を使用しなくても良くなります。

踏み台サーバのIPアドレス99.0.0.0 であれば、例えば taro.sample.99.0.0.0.nip.io というURLにアクセスすれば、それだけで 99.0.0.0IPアドレス、つまり踏み台サーバへアクセスしてくれるのです。

それに応じてNginxの設定を少し変える必要はありますが、管理するものが増えて煩雑になりやすい /etc/hosts を使わなくてよいのはそれなりの利点となるのではないでしょうか。

server {
    listen 80;

    server_name taro.sample.99.0.0.0.nip.io;

    location / {
        # ホスト名を指定する必要がある場合は、ここで指定
        proxy_set_header Host taro.sample.co.jp;

        proxy_pass http://10.0.0.0;
    }
}

まとめると、以下のようになります。

踏み台サーバと nip.io を兼用する方法とは

パブリックサブネットにある踏み台サーバからプライベートサブネットにあるサーバを見るようにし、ブラウザ等からはその踏み台サーバに対してアクセスするようにする。

踏み台サーバからプライベートサブネットにあるサーバを見られるようにするために、Nginx等でアクセスを流すようにする、

また、踏み台サーバにアクセスするために、nip.io で指定のURLから踏み台サーバのIPアドレスにアクセスするようにする。

利点

  • 踏み台サーバがあれば、それだけで開発環境にアクセスできる
  • /etc/hosts を使う必要がない

欠点

  • 踏み台サーバにNginx等の設定が必要になる
  • URLの命名が、 nip.io の形式に縛られる

最後に

最近は開発環境がコンテナ化されている例も多く、その場合は今回のような設定はあまり必要ないかもしれませんが、例えば何かしらの理由でコンテナ化ができなかったり、全体的に古くからある環境でまだまだサーバ上で開発環境が動いている場合は、もしかしたら上記のような設定も必要になってくるかもしれません。

3つのどれが一番いいというわけではなく、それぞれの利点・欠点をもとに今の状況でもっとも良いものを選ぶのが適切かと思います。 参考にしていただけると幸いです。

社内イベントでライブコーディングを実施しました!

エキサイト株式会社でモバイルアプリ開発に携わっている奥田です。 本日は社内イベントでTODOアプリの作成をライブコーディングしたことを記載していきます。

なぜライブコーディングをしたのか?

弊社ではアプリ開発において一部Flutterを採用しています。 またFlutter界隈が盛り上がっていることもあり、アプリ開発を専門にしている方以外にも興味を持ってもらう機会が多くなりました。 そこで社内イベントで簡単なTODOアプリの作成風景をライブコーディングをすることで、実装のイメージを掴んでもらうことになりました。

当日の作成物!

機能としてはボタンタップ時に文言をリスト追加、対象アイテムの削除です! これらを制限時間15分という短い時間で実装しました。 製作物のgifを掲載しておくのでイメージがつきやすいかと思います!

当日の様子を見てみましょう!

15分という限られた時間で弊社のアプリエンジニアで解説、実装に分かれてライブコーディングをしました。写真を使用しながら、当日の流れを雰囲気を伝えていきます!

※感染防止対策を徹底し、開催しました。

アプリのUIが構築されていく様子をみなさん真剣な眼差しで見ていただけました! アプリの実装が完了した時は自然と拍手がおこりました👏👏

また参加者のみなさんから質問をたくさんしていただき、真剣に受け答えするエンジニアの姿が印象的でした!!! とてもいい交流ができたと思っています。

参加者の反応

実際に目の前でUIが構築されていく様子を見せることができ、アプリに興味を持ってくれる方が増えてくれたと思います。 ここで参加者の感想をいくつかピックアップして載せていきます!

  • 社内では人口の少ない技術について、誰でもわかりやすくデモを行っている点が良かった。

  • Flutterの特徴が現れていた社内全体レベルのライブコーディングは初めての試みだったかと思いますが、引き続き他にもいろいろ見てみたいなと思いました。

  • Flutterみたことない人たちにはリアルタイムで変化が起きるのは結構楽しい内容だったと思います。

  • 文字がもう少し大きかったらもっとよかった。

反響はとても良いものでしたが、文字の大きさの調整など配慮が足りない部分もありましたので次回からは改善していきたいです。

感想

ライブコーディングの取り組み自体が初の試みでしたが、無事成功してホッとしています。Flutterでのアプリ実装の強みであるUIの反映の容易さという点を活かし、参加者の方々の興味を惹くことができたのも良いポイントでした。そのため、社内からの反響もよく、機会があれば今回の反省点を活かして再度挑戦してみたいです。

最後に

最後に、エキサイトではフロントエンジニア、バックエンドエンジニア、アプリエンジニアを随時募集しております。長期インターンも歓迎していますので、興味があれば連絡いただければと思います。今回の記事を読んで少しでも興味が湧きましたら是非応募お願い致します!!

就業型インターンの募集情報です! www.wantedly.com

募集職種一覧はこちらになります!カジュアル面談からでも構いません。 www.wantedly.com

また社内イベント全体の模様は第1回テクデザビアバッシュ開催しました!【社内イベントレポ】をご覧ください!

2022年度新卒技術研修を実施しました!

はじめに

エキサイトでエンジニアをしているたからだ(amochan0313)です。 このたび、2022年度新卒技術研修を実施しました。 今回は、研修内容や工夫したポイントをお伝えするとともに、実際に使用した講義資料を一部公開します。

新卒技術研修の概要

新卒技術研修の詳細を話す前にまずは概要の説明です。

新卒エンジニアの人数

3人

研修期間

4/18 ~ 5/31

コンテンツ
場所

オンライン

  • 講義は Zoom で実施
  • システム開発時のコミュニケーションでは主に Discord を利用

研修の目標

エキサイトは多くのサービスを提供しており、その分チームも多く存在します。各チームで技術スタックやアーキテクチャ、細かい開発フローなどが異なります。そこで、新卒の業務への適応は各チームでタスクをこなすことで行い、この新卒技術研修では「業務で活躍するために必要となる基礎技術を学ぶ」ことを目標に実施しました。

講義

まずは社員による講義を紹介します。

業務で活躍するために必要となる基礎技術を学ぶ」ということで、今回は幅広い分野の講義を用意しました。講義数は 11 で、全部で約2.5日かけて実施しました。 今回動画は公開していないですが、講義の様子はすべて録画してあり社内では共有しています。

良いコードの書き方

良いコードの定義を「読みやすいこと」、「拡張しやすいこと」、「安全なこと」の3つにしぼって解説したコーディングに関する講義です。

クリーンアーキテクチャ

クリーンアーキテクチャーの基礎を学ぶ講義です。クリーンアーキテクチャーで重要となる、「SOLID の原則」、「非循環依存関係の原則」、「安定依存の原則」、「安定度・抽象度等価の原則」などを解説し、アプリケーションの依存方向の重要性を理解する内容でした。

Docker

Docker の基礎を学ぶ講義です。研修ではコンテナを操作するハンズオンも行いました。

DNS

DNS の基礎を学ぶ講義です。研修では Route53 を使ってレコードの登録や委任を行い実際に名前解決をするハンズオンも行いました。

AWS

クラウドを利用する意義やデプロイの重要性に加え、システム開発パートでも利用するデプロイの具体的な方法に関する講義とハンズオンを行いました。

エンジニアのマインド

エンジニアとして働く上で重要となるマインドに関する講義です。

フロントエンド

フロントエンド技術の変遷に関する講義です。

RDB

SQL の問題を解きながら RDB の基礎概念を学ぶ講義・ハンズオンを行いました。 主に「データサイエンス100本ノック」からいくつか問題をピックアップして一緒に解いていきました。

ソフトウェアテスト

ソフトウェアテストの基礎を学ぶ講義です。研修では PHP のサンプルコードで実際に単体テストを書くハンズオンを行いました。

Web サービスのセキュリティ

Web サービスを提供する上で知ってほしいセキュリティに関することを紹介する講義です。Web セキュリティでまずはおさえておくべき XSS,SQLi,CSRF の解説と事例を紹介し、自社サービスを例にその他の観点でセキュリティを意識して実装した内容などを紹介しました。

インフラストラクチャー

社内の共通システムの紹介と共通システムのメリット・デメリット、共通システムの今後の方針を紹介する講義です。

システム開発

次にシステム開発について紹介します。

お題として出したのは、会社で購入している検証端末の貸し出しシステムです。指定したいくつかの機能を盛り込むことを必須条件として開発してもらい、オプションの追加機能については時間が許す限り実装してもらいました。 このシステム開発のパートは以下の2つのねらいをもって実施しました。

  • 講義で習ったことを開発を通して実際に使うことで身につけてもらうこと
  • 新卒エンジニア個々人で苦手意識のある分野や経験したことのない技術領域へチャレンジしてもらうこと

それぞれ簡単に説明します。

1つめは、講義を聞いて理解したことを実際に使えるようになるための練習場としてシステム開発パートを使ってもらいました。例えば、開発環境では Docker を使って開発してもらったり、プロジェクトのテストコードは必ず書いてもらったりしました。

2つめは、今回は新卒エンジニアが3人しかいなかったので個々人の苦手分野や経験したことのない技術領域にチャレンジできるように工夫しました。 元々新卒の3人は入社前にエキサイトの長期インターンを経験していたので、その時のメンターの方に「得意・苦手な技術」や「新卒としてチームにどういう状態で入ってきて欲しいか」のようなヒアリングを行い、そのヒアリングを元に、例えばAPI とフロントの担当メンバーを割り振りました。 この方法が可能だったのは今年度の新卒エンジニアが3人と少数かつ3人とも長期インターンを経験していたからだったと思います。

3人で約1ヶ月間チーム開発を行い、最終発表はエキサイトHDの社員全員が参加する MTG の場で、開発したツールの説明とデモを実施し、社内ツールとしてリリースしました。

まとめ

今回は2022年度新卒技術研修の紹介をしました。
約1.5ヶ月の研修期間で、用意したすべての講義を実施することができ、お題のシステムもリリースできてひとまずは良かったです。もちろん講義・システム開発パートのそれぞれで反省点はあるので、それらを考慮して今後はさらに良質な研修を実現できればと考えています。

エンジニアを志す方や各社の新卒エンジニア研修において、今回ご紹介した研修内容や講義資料がお役に立てれば幸いです。また、この記事を読んで、少しでもエキサイトに興味を持っていただけると嬉しいです。

最後に、エキサイトではフロントエンジニア、バックエンドエンジニア、アプリエンジニアを随時募集しております。長期インターンも歓迎していますので、興味があれば連絡いただければと思います。

就業型インターンの募集情報です! www.wantedly.com

募集職種一覧はこちらになります!カジュアル面談からでも構いません。 www.wantedly.com

【テクデザBeer Bash】Canvaによるバナートレースライブ

こんにちは、デザイナーの山﨑です。

テクデザBeer Bashを開催時に、デザイナーの山﨑・鍜治本で「Canvaによるバナートレースライブ」を開催しました。

バナートレースと銘打っていたのですが、今回トレースしたのは某雑誌のトレースです。(他社のデザインなのでぼかしを入れています。)

制限時間は15分だったので、時間内に制作できるようにコピペできる事前に作ったデザインを用意していました。(普通に作ったら20分かかりました…)

工程としては、タイトルなどの主要なデザインの作り方を解説→「この工程を繰り返したものはこちらです」と事前に用意したデザインをコピペする3分クッキング方式にしました。

最後に作ったデザインをCanvaのスマートモックアップに当てはめて完成です!

当日に備えて何度もリハーサルを行っていたので、当日はちゃんとサクサク作ることができてよかったです!

最後に、エキサイトではデザイナー、フロントエンジニア、バックエンドエンジニア、アプリエンジニアを絶賛募集しております!

興味があれば連絡いただければと思います🙇‍♀️

それではまた!

www.wantedly.com

【Canva布教】Canvaトレース道場を開催してみた

はじめに

こんにちは、メディア事業部デザイナーの山﨑です。 先日メディア事業部でビジネス・エンジニア職向け「Canvaトレース道場」を開催したので、それについて書こうと思います。

開催のきっかけ

ビジネス職の方に向けてCanva説明会を行っていたところ、「説明だけじゃなくて、Canvaでトレース講習とかできない?」とリクエストされました。

少人数で行ったところ「Canvaの使い方覚えられたしデザインの勉強になった!」と好評だったので、メディア事業部全体で行い規模を広げる形にしました。

開催の様子

「Canvaトレース道場」の概要はこんな感じです。

オフライン開催をしたのですが、募集人数を5名のところ6名が参加してくれました!

お題のバナーに沿って全員が同時に作り始めるのは楽しかったです!(見本となるバナーは他社のものなのでぼかしを入れました。)

作ったバナーは最後にスマートモックアップに適用して終了しました。

Canvaは制作したクリエイティブを簡単にモックアップにすることができて最高です。

おわりに

個々のCanvaのテクニック向上によって総合的なクリエイティブ能力・理解の底上げを目指す上で、今回のCanvaトレース道場はその一歩になったかなと思いました。

最後に、エキサイトではデザイナー、フロントエンジニア、バックエンドエンジニア、アプリエンジニアを絶賛募集しております!

興味があれば連絡いただければと思います🙇‍♀️

それではまた!

www.wantedly.com

Flywayで、S3にあるSQLファイルを使ってマイグレーションする方法

こんにちは。 エキサイト株式会社の三浦です。

JavaのアプリケーションでDBを扱っている場合、DBのマイグレーションのためにFlywayを使っている方も多いのではないでしょうか。

今回は、マイグレーションに使用するSQLファイルについて、ローカルではなくS3上にあるものを使用する方法を紹介します。

Flywayとは

Flywayは、DBのマイグレーションに使用するツールです。

公式には以下のように説明されています。

flywaydb.org

Version control for your database

Robust schema evolution across all your environments. With ease, pleasure, and plain SQL.

Flywayを使用することで、例えば開発環境用のDBをローカルPCのコンテナに簡単に構築することができたりします。

マイグレーションSQLファイルの場所

FlywayでDBのマイグレーションを行うには、マイグレーション先DBとマイグレーションSQLファイルを指定する必要があります。

以下のような形です。

# DB指定
flyway.url=jdbc:mysql://localhost:3306/sampledb
flyway.user=sample-user
flyway.password=sample-password

# SQLファイルのパス指定
flyway.locations=filesystem:path/to/sampledb/schema

このようにすれば、ローカルPCの指定パスに存在するファイルを使ってマイグレーションを行ってくれます。

これで十分な場合もあるかもしれませんが、例えばアプリケーションをGithubでバージョン管理しており、本来はマイグレーションSQLファイルも同様に管理したいものの、DB内のテーブル数やその中のレコード数がかなり多かったり、あまり外部に公開したくないデータが含まれていたりして、バージョン管理が難しく、結果直接ファイルをローカルPCに持ってくるのが難しい場合もあるでしょう。

そういった場合は、Flywayから直接S3上のSQLファイルを指定することができます。

S3上のマイグレーション用ファイルを使用する方法

S3上のファイルを使用するには、まずAWS認証のための設定をする必要があります。

認証情報をローカルPCに入れる

まずは該当S3バケットが存在するAWSアカウントで、認証用のIAMユーザを作成します。

その後、 aws configure コマンドでローカルPCにクレデンシャル情報を設定してください。

この時、設定したアカウントの profiledefault であればそのままで構いませんが、もしそれ以外であれば、環境変数で以下のように設定します。

AWS_PROFILE={該当アカウントのprofile名}

これで、Flywayで使用したいAWSアカウントの認証情報の設定が完了しました。

FlywayでS3を使用できるようにする

続いて、FlywayがS3を使用できるようにします。

build.gradleに以下のように設定します。

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        // バージョンは必要に応じて変更
        classpath platform('software.amazon.awssdk:bom:2.17.160')
        classpath 'software.amazon.awssdk:s3'
    }
}

これで、FlywayでS3を使用できるようになります。

ロケーション指定

ここまでくれば、後はS3上のロケーションを指定するだけです。

# DB指定
flyway.url=jdbc:mysql://localhost:3306/sampledb
flyway.user=sample-user
flyway.password=sample-password

# SQLファイルのパス指定
flyway.locations=s3:sample_bucket/path/to/sampledb/schema

以上のように設定することで、「sample_bucketバケット上の「/path/to/sampledb/schema」に存在するSQLファイルを、マイグレーション用ファイルとして使用してくれます。

また、例えば「テーブルのスキーマ用のSQLファイルはGithubで管理してローカルPCに落とし、レコード情報だけはS3に持っておきたい」等の場合は、以下のようにカンマ区切りで複数指定することもできます。

# DB指定
flyway.url=jdbc:mysql://localhost:3306/sampledb
flyway.user=sample-user
flyway.password=sample-password

# SQLファイルのパス指定
flyway.locations=filesystem:path/to/sampledb/schema,s3:sample_bucket/path/to/sampledb/schema

S3上のファイルをマイグレーションファイルとして使用する際の注意点

S3上のファイルを直接マイグレーションファイルとして指定するのは非常に便利に使えますが、いくつか注意点があります。

  • AWSアカウントの認証が必須になる
  • マイグレーションのたびにS3のファイルを見に行くため、S3上に存在するファイル数が多くなったり、ファイル容量が大きくなるほど時間がかかるようになる
  • FlywayのCommunity版だと、S3上のファイルは100ファイルまでしかマイグレーションできない

上記の点が許容できない開発の場合は、例えば自分でS3からファイルをローカルPCにダウンロードした上で、ローカルファイルのみを指定してマイグレーションするなどの方法もあるので、そういった方法で回避するのもいいかもしれません。

最後に

DBが大きくなるのに比例して、DBマイグレーションの悩みは大きくなっていくと思います。

今回の方法で、そういった悩みが解決したら幸いです。