スタイル・エッジ技術ブログ

士業集客支援/コンサルティングのスタイル・エッジのエンジニアによるブログです。

バッチ処理について

サーバーサイド

はじめに

はじめまして！スタイル・エッジLABOのKKです！
昨年7月に中途入社し、ドキドキワクワクなエンジニアライフも7ヶ月目に突入しました。
本当に、早いものです。

私は未経験でエンジニアデビューしたので、最初の3ヶ月は有り難いことに、学び多き研修用Webアプリを作らせていただきました。
その後、プロジェクト配属時に意気揚々と「まずはバックエンドの処理を書けるようになりたいです！（かっこいいから..）」と話し、数あるプロジェクトの中でもバックエンド色の強いプロジェクトに配属され、日々切磋琢磨して取り組んでいます。

そんな中でも私が、かっこいい！便利！と感じる機能が「バッチ処理」です✨

初めは「バッチ処理とは..」となっていた私ですが、今ではその威力を感じる毎日です。

今回は、そんな私が普段扱っている、バッチ処理について紹介していきます！

バッチ処理とは

そもそもバッチ処理とは何か、について書いてみます。
まず"バッチ(Batch)"には「一束、一群、一回分、一団」という意味があります。
つまり、バッチ処理とは、「一定量のまとまったデータを集め一括処理」することなのです。

大量のデータに対して処理が走るので、コンピュータのリソースを圧迫して操作に支障をきたすことを防ぐため、夜間に動くものが多いです。

身近なバッチ処理でいうと、銀行の夜間バッチなどが挙げられます。
通常、ATMでお金を預け入れるような単体処理の場合、即座に反映されますが、企業の給与振り込みや企業間取引などは、膨大なデータを扱うため夜間バッチとして行われています。

今私が所属しているプロジェクトでも、夜間に大量のデータを取り込み、一定のロジックに沿って分析業務などを行なっています。

バッチ処理のメリット

ここからは、バッチ処理の良いところを書いていきます。

タスクスケジューリングによって処理を予約できる

バッチ処理の最大のメリットは、あらかじめ決められた時間に決められた処理を自動で実行可能なことです。

そのため、一度ロジックを作ってスケジューリングすれば、そこに人員は必要ありません。

例えば、 「○月●日の△時▲分に処理Aを実行する」のように特定の時間に実行させることもできれば、「毎週月曜日の深夜1時に処理Cを実行する」のように定期的に実行させることもできます。

大規模なシステムではこの方法で、人が動かない深夜帯などに処理を実行させているのですね！

また特に大量のデータを扱う処理であれば、人が操作するのは時間がかかりすぎて現実的ではないため、効率的に処理を行う上で、バッチ処理は欠かせないものです。

ヒューマンエラーが排除できる

通常、人がデータ処理を行うと、データの数が多いほどミスする可能性も上がってしまいますが、バッチ処理では全てのデータが決められた順番で処理を通っていくため、処理を正しく書けてさえいれば、人為的な操作ミスは起こらなくなります。

バッチ処理のデメリット

処理内容がブラックボックス化しやすい

私が思うバッチ処理のデメリットは、処理内容が複雑になり、ブラックボックス化しやすいことです。

大量のデータであるほど、全てのデータが全く同じ処理を通るのではなく、データの種類によって条件分岐をし処理を分けることが多いです。

また全自動で実行されるので、開発担当者しかシステムの全容を把握していない、というパターンも起こる可能性があります。

そのためスタイル・エッジLABOでは、そのロジックが誰でもわかるような設計書を作り、わかりにくいところはプログラムだけでなく、設計書も改良していくことを大切にしています！！ 😎

エラーによってデータ処理が完了しないことがある

先にも述べたように、バッチ処理は重くなりやすいため、人が操作しない深夜帯などに実行されることが多いです。

ただ深夜帯に行えば全て問題ない訳ではなく、処理時間が長く、システムに負担がかかることも事実です。

そのため、SQLの書き方やアプリケーションの構造によっては、深夜帯にエラーが起きて全ての処理が完了していなかった、なんてことも起こり得るのです。

そのためスタイル・エッジLABOでは、業務で利用するチャットにエラー通知が届くようにしており、早期発見のための工夫をしています。

このように、バッチ処理を扱う際にはただプログラムを書くだけではなく、突然のエラーに常に備えている必要があります。

この辺りの対策はまだまだ私も勉強中ですが、日々システムに触っている中で、「こういう書き方をすると、データ量が多い時にエラーが起こる可能性があるんだ！」と、学んでいます！

最後に

今回は私が普段扱っているバッチ処理について書いてみましたが、いかがでしたでしょうか？
バッチ処理はとても便利で業務効率を上げてくれる反面、ブラックボックス化しやすいため、コード内に補足説明を入れることや、分かりやすい仕様書を作成して日々更新していくこと、が大切だと思っています。💪

またただ動くコードを書けばいいわけではなく、突然のエラーを起こさないための書き方やシステムのメンテナンスも必要になってきます。

とはいえ、バッチ処理は様々なシステムでその威力を発揮しています。

それくらい求められている方法ということですね！✨

システムを長く快適に使えるために、このバッチ処理を活用しながら、これからも改善を繰り返していきます！

☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください！

recruit.styleedge-labo.co.jp

WSL2について

ツール

はじめに

こんにちは！スタイル・エッジLABOのNTです。
今年の4月に入社し、早くも2021年が終わろうとしています。
入社してからの毎日は学びの日々でした！
社会人としてエンジニアとして成長を実感しています。

私は入社してから半年間、士業を支援するプロダクトの開発・保守の業務に携わりました。
プロジェクト配属直後、開発に必要なLinux環境を構築しました。
今回は、その際に使用したWSL 2について紹介したいと思います！

WSL 2とは

まず先ほど登場したWSL 2についてです。
正式名称はWindows Subsystem for Linux 2です。
こちらは一言で説明すると「Windows10上でLinuxを動かすことができる仕組み」です。
WSL 1の後継であり、両者には違いがいくつか存在します。

WSL 1とWSL 2の違い

それでは、WSL 1とWSL 2の違いについて3つほど紹介します！

・完全なLinux

WSL 1ではWindows上で完全にLinuxが動作しているわけではありません。
LxCore.sys/Lxss.sysと呼ばれるNTカーネルドライバがLinuxシステムのコールを受け取り、
Windowsシステムコールへと変換しています。
WSL 1は、LinuxとWindowsの間に立ち「翻訳」する役割を果たしています。
しかし、この「翻訳」が完全でなかったため一部ソフトウェアが動作しないこともありました。

WSL 1の後継であるWSL 2では、Hyper-Vを利用しLinuxカーネルそのものを動作させることができます。
Hyper-Vは一台のコンピューター上で複数の仮想マシンを稼働させ、
それぞれ別のオペレーティングシステム(OS)を起動することができます。
Hyper-Vを用いて仮想化することで、WindowsカーネルとLinuxカーネルを切り離すことが可能となり
Windows上でLinuxを動作させることができるのです。
バイキングで例えるなら、大皿(Hyper-V)の上にお寿司(Windowsカーネル)とカレー(Linuxカーネル)を
一緒によそう欲張りな状態です!

参考：「WSL 2」が正式リリース！ ～「WSL 1」とのメリットは？ 「Windows Terminal」にも注目 - 窓の杜
　　：完全なLinuxがWindows 10上で稼働する？ 「WSL 2」とは：Windows 10 The Latest - ＠IT

・ファイルアクセス速度

WSL 1では、ファイルアクセス速度が遅いとされていましたが、
WSL 2では改善されファイルI/Oパフォーマンスが向上しています。
実際どの程度高速になるかは、実行しているファイルシステムやアプリによって変わります。
Microsoftのドキュメントには「git clone、npm install、および cmake を使用する場合は、
約 2 倍から 5 倍速くなります。 」と記載されており、かなり速くなっています！

参考：WSL バージョンの比較 | Microsoft Learn

・IPアドレスが異なる

WSL 1は、Windowsカーネルを利用しているため、Windows 10と同じIPアドレスを使用します。
WSL 2では、仮想化によってWindows上にWindowsカーネルとLinuxカーネルが存在するため
ホストであるWindows 10のIPアドレスを使用することができません。
そのため、Windows 10とは別のIPアドレスを使用します。
WSL 2は、IPアドレスの割り当てをWindows 10の起動時に行い、必ずしもIPアドレスが一定ではありません。
環境構築で詰まりやすい点でもあるため注意が必要です。

参考：前バージョンから大幅に性能向上した新Linux環境「WSL 2」の実力を探る：Windows 10 The Latest - ＠IT

最後に

今回私が普段使用しているWSL 2について紹介しました。
Windows上で本物のLinuxを手軽に動かすことができるという最大の利点が伝わりましたら幸いです。
また、WSL 2は環境構築が比較的優しいため、初めてLinux環境を作る際にもおススメいたします！

私がプロジェクトに配属された際に、
代表から「スタイル・エッジLABOでは、WSL2以外で環境構築をしている社員が多いため、
新しくWSL 2を使用した環境構築手順を確立してほしい」と頼まれました。
ここから既存の技術や考えに捉われず、新しい技術を積極的に取り入れる風土があると感じています。
エンジニアとして成長することができるそんな環境に身を置いてみませんか？

☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください！

recruit.styleedge-labo.co.jp

フレームワークについて

Laravel

はじめに

はじめまして！スタイル・エッジLABOのYHです。
今年の４月に新卒として入社し、早いもので半年が過ぎました。
時間の流れの速さに震える日々を過ごしております…。

私は６月にプロジェクトに配属されてから現在まで、所謂「開発系」の業務に携わってきました。
LABOではPHPフレームワークを利用した開発を行っており、
9月まで配属されていたプロジェクト内ではFuelPHPを利用していました。
はじめこそ四苦八苦していたフレームワークを用いたコーディングも少しずつ慣れてきて、
「FuelPHPと仲良くなれたかも！😊」と思っていた矢先、
10月から新たにジョインしたプロジェクトではLaravelの利用がスタート…！
まだまだ戦っている最中ではありますが、FuelPHPとLaravelの違いについて少しまとめてみました。

エンジニア歴半年ではありますが、初心者だからこそ気づいた違いもある（はず!）ということで、
温かい目でお読みください🙋‍♀️

０．フレームワークとは

違いを列挙する前に、そもそもフレームワークとは何かということについて整理してみます。
Wikipediaにはフレームワークについて以下の記載がありました。

ソフトウェアフレームワーク（英: software framework）とは、プログラミングにおいて、アプリケーションソフトウェア等の実装に必要となる一般的な機能や定型コードを、ライブラリとしてあらかじめ用意したものである。

(https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF)

プログラミングにおける土台・雛形を用意してくれているのがフレームワークであり、
開発に必要な機能があらかじめ実装されているため工数を減らせるという利点があります。
フレームワークも各言語によって様々な種類があり、どのフレームワークにも得意・不得意な点があります。
何を実装したいか、どのように開発していきたいかによって選定する必要があり、
FuelPHPとLaravelはPHP言語のフレームワークの一種、ということになります。

実装するにあたってフレームワークは
「これがないとプログラミングは不可能！」 というものではありません。
フレームワークがなくてもプログラム自体は書くことはできますし、
独自機能による制限がない分、自由度は高くなると思います。
しかし、個人開発ではなくチームで開発するとなると、
各人が好きなように設計しコーディングしたものを製品として運用するのは
セキュリティ的にも脆弱性が高くなり、なにより保守できなくなってしまいます。
そこでフレームワークを用いて、同じ土台である程度の規約や設定に則ることで、
個々の経験やスキルの差をある程度吸収しつつ、一定の品質のプロダクト開発を実現するというのが
チーム開発においてフレームワークを導入する利点だと思います。

１．学習コスト

FuelPHPでコーディングをしているとき、一番困ったのが
「探しても知見が出てこない（探すのが困難）」ということでした。
調べが甘いのかな？と思い、検索ワードをあれやこれや変えてみても解決方法が見当たらず、
最終的には全然違うフレームワークでのコーディング方法が出てきて行き詰まることもしばしば😥
プロジェクト内外の先輩方にかなり助けてもらっていなんとか解決してきたのですが
コーディング初心者からすると情報がないという状況はかなり辛かったです…。
その点Laravelは公式ドキュメントが充実しており、非公式ですが日本語にも翻訳されています。
ユーザの個々の知見に頼らずとも公式ドキュメントに利用方法や解決策が詳細に記載されているので、
かなり助かっています。
また具体的な実装方法や、エラーの際の詳細な解決方法などといった
公式ドキュメントでカバーしきれない部分はユーザが投稿した情報をネットで多く手に入れることができます。
以上を踏まえて、Laravelの方がFuelPHPよりも学習コストが低く、
プログラミング初心者でも挑戦しやすいと感じました。

２．コーディングの柔軟性・拡張性

FuelPHPは「規約より設定」を重視して作られていることからも、かなり柔軟性の高いフレームワークです。
またcoreの拡張が容易だったりコーディング規約も比較的緩いことから、
ある程度は自由にコーディングすることができます。
（入社して少し経ったころ、先輩社員から
「FuelPHPは生のPHPを書いている感覚と似ている」と教えていただきました。
当時は「そうですかね…？🤔」くらいの感想だったのですが、確かにLaravelと比較すると、
「独自の機能を持った生のPHP」という扱いができると思います。）

一方Laravelは、独自のメソッドが充実しており、開発時においてはそれらを活用することで
自前開発をする必要性を抑えることが出来ます。
フルスタックフレームワークとしての完成度が高いため、
初心者にとっては始めやすく、上級者にとっても開発時の煩雑さを減らせるので、
バランスの良いフレームワークなのではないかな？と思います。

３．フレームワーク独自機能の量

FuelPHPではフレームワークとしての機能にないため、自前で実装を行うことも時々あったのですが、
実装に時間がかかってしまう場面が多々あり、プログラミング初心者の私は
かなり悪戦苦闘しながら開発を進めていました。
（そのたびに先輩方に助けていただきました…！😳
この「自分の技術を互いに共有し合う」文化は、私がLABOで一番好きな特徴です✨）
その点、Laravelでは機能が充実しているため、実装自体がとても簡単です。

最近感動したのがページネーションの実装です。
ページネーション自体は、かみ砕くとそこまで難しいことはやっていない…ようなのですが、
データを分割したり、２ページ目に表示させるデータが何番目のデータになるのかだったり、
これは工数的にどのくらいかかるんだ…？？と冷や汗をかいていました。
しかし、Laravelの優秀な機能のひとつにページネーション作成機能があるため、
ほとんどデータを操作することなく、ほんの少しの時間で実装が完了しました。
これは感動モノだったのですが、裏を返せば
「どのような処理が走っているかはわからないけれど、なんか動いた」 という状態であり、
私のような初心者プログラマが訳も分からずフレームワークの機能で実装していると、
バグが発生したときに対処できない可能性も出てきています。
実装に省略できた時間を処理内容を理解する時間に充てるなどして、
機能に頼りすぎないことも大切かな、と感じました。

最後に

FuelPHPとLaravelの違いについてまとめてみましたが、いかがだったでしょうか？
今回紹介した内容と私の観点を含めて、FuelPHPとLaravelについて以下の表にまとめてみました。
なんだかこう見ると「Laravel圧勝！？」という感じなのですが、
プログラミング学習という点においてLaravelは
メソッドが豊富な分処理の内容がブラックボックスになりがちという特徴があると思います。
私のようなプログラミング初心者の場合は、メソッドの内容をよく理解したうえで使用していくのが
今後の知見を増やすという意味でも大切だと感じました。

フレームワークを利用すると素早く簡潔に実装できるという利点があります。
また初心者でもコーディングしやすく、理解もしやすいため、技術力の向上も早くなると思います。

弊社ではプログラミング未経験でも、かなり本格的に実装を経験することができ、
また学びあう風土があるため、エンジニアとしてどんどん成長することできる環境です！

☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください！
recruit.styleedge-labo.co.jp

OSI参照モデルとネットワークを構成する機器（ルータ、スイッチングハブ）

インフラ ネットワーク

はじめに

はじめまして！スタイル・エッジLABOのYAです。 今年度新卒で入社しました！
僕は入社後のプロジェクト配属の時に、「ネットワークに関わってみたいです！」と希望を出したので、
現在は弊社や弊社のクライアントの方々のネットワークを構築・管理する役割を担っています。
基本的に希望が通る環境なので、自分の興味や関心のあるプロジェクトに所属できるのは
ありがたいなと思います😊
今回はそんな僕が普段設定・管理しているネットワークデバイスについて紹介していきます！

ネットワークデバイスとは？

ネットワークの中でのデータのやり取りをコントロールする機器たちのことです。
コントロールというのは、データをどこに向かって送るのか、逆に送らないようにするのか
などといった 通信におけるデータの流れを制御することです。

ネットワークでの通信のルール

このデータの流れを制御するには、各メーカーの各デバイスで共通したルールが必要です。
たとえばA社の製品とB社の製品が異なるルールでデータをやり取りしていたら、通信ができなくなります。
ちょうど人がお互いに知らない言語でコミュニケーションを取ろうとしてもうまくいかないようなものです。

そこで、通信のベースとなる共通のルールを定めるために、OSI参照モデルというものが生み出されました。
OSI参照モデルは、7つの階層構造で表されます。
そして、各階層のルールにしたがって通信を行うネットワークデバイスを定義します。
こうすることで、ネットワークデバイスたちはたとえ製品が異なったとしても、
各階層ごとの共通のルールにしたがって通信ができるようになります。
たとえば、Ａ社、Ｂ社関わらず第３層を担当するデバイスは、第３層のルールに基づいて
データを送受信し、同様に第２層担当のデバイスは第２層のルールに基づいて
データを送受信するというように、各デバイスは各階層のルールにしたがってデータをやり取りします。
また、ルールを階層構造で表すことで一連の通信の中で各デバイスの役割分担ができるようになります。

ここからは各層のルールと代表的なネットワークデバイスとして
第２層を担当するスイッチングハブと第３層を担当するルータについて説明します！
１、４ー７層には申し訳ないですが、ここでは割愛させていただきます😌

　　　　　　

〇スイッチングハブ

第２層のネットワークデバイスです。
第２層では、ざっくり説明するとMACアドレスという情報をもとに、
同じネットワーク内の直接接続されている機器とデータをやり取りします。
MACアドレスとは、各機器に割り当てられる一意の番号のことで、
同じネットワーク内で「誰に」データを送るのかを表すための情報です。
スイッチングハブは、自分に接続されているPCなどの機器のMACアドレスを認識し、
そのMACアドレスの情報をもとに正しい送信先にデータを送り、
正しくない送信先にはデータを送らないようにして、データのやり取りを制御します。

〇ルータ

第３層のネットワークデバイスです。
第２層が同じネットワーク内の機器とのやり取りを行っていたのに対して、
第３層では、異なるネットワークにある機器との間でデータをやり取りします。
また、データをやり取りするための最適な経路を決定します。

ここで、話は少し逸れますが異なるネットワークとは何かについて説明します。
現在は世界中がネットワークに接続し、どこからでも動画の視聴やSNSでのやり取りが可能です。
このような世界規模のネットワークは、大きな１つのネットワークがあるのではなく、
実は小さな異なるネットワークが互いにつながることで構成されています。
日本の自宅から海外にいる友人にSNSでメッセージを送るとき、そのデータは自宅のネットワークを出発し、
SNSを管理するネットワークやその他の様々な小さな異なるネットワークを経由して、
友人の自宅のネットワークに到着します。

ルータはこのような異なるネットワークとのデータのやり取りをIPアドレスという情報をもとに行っています。
IPアドレスは、「どこの」ネットワークの「誰に」データを送るかを表すための情報です。
この情報をもとに、ルータは指定された異なるネットワークにデータを送信し、
さらにそのネットワーク内の別のルータが次の異なるネットワークにデータを送信することで、
次々にネットワークを経由してデータが正しい送信先に送られます。

最後に

今回はネットワークデバイスのうち特に代表的なスイッチングハブとルータについて紹介しました。
一言でネットワークや通信といっても、今回のようなデバイス間のものだけでなく、
クラウドサービスやシステム間でのネットワークや通信などもあり、非常に奥が深いです🤔
今後は、ネットワークに関する知識を武器にさまざまな分野に足を踏み込んでいきたいです！
このように自分の興味のある分野から派生して、興味・関心を広げていけるのは
エンジニアとしてとても楽しいですし、弊社にはそれを実現するための環境が備わっていると思います！


☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください！
recruit.styleedge-labo.co.jp

社内でITのお困りごとなら「SIP」におまかせ✨

エンジニアコミュニケーション

はじめまして！ スタイル・エッジLABOのSMです。
今年の4月に新卒未経験で入社しました🙌

入社して半年が経ちましたが、日々新しい発見の連続で、沢山のことを学んでいます！

私は6月よりSIPに所属しているので、今回はSIPについてご紹介します🔍

▶そもそも「SIP」って？

過去記事の祝 🎉「CSIRT」＆「SIP」の発足！！でも紹介しましたが、
SIP(シップ)とは社内IT支援室の略称で、
スタイル・エッジ・グループ全体から寄せられるIT関連の相談事への対応、
全クライアント事務所に対するIT各種サポートなどを全面的に担う組織です！

　　　　　　　　　　　　　　　

ではITサポート対応は具体的にどんな流れで行っているのでしょうか🔍

▶ITサポートの流れ

▷問い合わせをキャッチ

まずITサポートの問い合わせフォームから問い合わせが来ます📫
問い合わせ内容をSIPメンバーが確認し、SIPメンバーのうち誰が担当するかを決定します。
担当者が決まったら、担当者は問い合わせ者に直接連絡し、問い合わせ内容の詳細をヒアリングします👂

▷ヒアリング

　　　　　　　　　　

ヒアリングは簡単そうに見えて、ITサポートにおいてはとても重要なフローです！
実際にお会いして状況を直接見ることができれば、どう解決すべきかわかりやすいものですが
各クライアント事務所からの問い合わせや、在宅ワークが増加していることにより
正しい状況をチャットで把握しなければなりません。

時には通話、画面共有などを駆使して状況を正確に把握します🔍

▷解決

状況が把握できたら、原因の切り分けを行います✂

例えば「PCがネットに繋がらなくなりました！」という問い合わせの場合、
PCは有線なのか無線なのか、他のPCも同様に繋がらないのか、などなど…
切り分けをすることで原因がどこにあるのかを突き止めます！

どうしても分からない場合は、他のSIPメンバーに相談することも。
試行錯誤して、解決まで導きます💪

▷今後の知見へ

解決した問い合わせは、全て内容を記録・共有し、今後の知見に役立てています📚

　　　　　　　　　

▶ITサポート事例

では実際に対応したITサポ－ト事例を紹介します！
あるクライアント事務所より「特定のモデムからPCが有線接続できません。」
との問い合わせをいただきました。
ヒアリングしたところ、「あるモデムに接続したPCだけネットワーク接続ができない」とのことでした。

しかし本当にPCに接続しているのはモデムなのでしょうか・・・？
モデムから直接PCを有線接続していることは考えにくく、もしかして「ハブ」のことを指しているのでは…
そう考え、ハブの写真をお送りし、「有線接続しているのはこちらの機器でしょうか？」と聞くと、
「それです！」とのこと！

また、同じルーターから繋いでいる他のハブに接続してネットワークが使用できるPCも
該当ハブに接続するとネットワークが使用できない、とのことなので
該当ハブを再起動していただいたのち、無事にネットワークに接続することができました✨

クライアント事務所の方からの問い合わせは、中々すぐに現地で対応することができないため
事象を一つ一つ確認することが大切ですね🔰

▶じゃあ、コードは書かないの？

確かに他システムを作っているメンバーに比べるとコードを書く機会は少ないですが
全く書かないというわけではありません💻

実は問い合わせをキャッチする仕組みにはGAS(Google Apps Script)が使われています✨

また、問い合わせ対応の抜け・漏れがないように、日毎の問い合わせまとめを確認したり
問い合わせ内容を記録する際に、問い合わせフォームに入力された内容から
必要箇所をピックアップして自動入力し、記録を短時間でできるようにしたり…
様々な場所でプログラムが動いています🔍

　　　　　　　　　　　　　　

▶最後に

今後ともスタイル・エッジ・グループ全体、そして全クライアント事務所のIT周りをサポートしていきます！
そして、皆様のITリテラシーの向上を目指すこともSIPの役目です。

スタイル・エッジLABOでは、一緒に働く仲間を募集しています！
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください✨

recruit.styleedge-labo.co.jp

「Jitsi Meet」でビデオチャット環境構築～共有ドキュメント「Etherpad」導入手順

ツール

はじめに

この4月よりスタイル・エッジLABOに新卒入社したK2です！
社会人生活にもだいぶ慣れ、落ち着いてきた今日この頃ですが、
エンジニアとしても日々成長できるよう毎日楽しんで業務に取り組んでおります。

ところでみなさん、このご時世なのでリモートで作業することや、
対面での会議などはなくなりビデオ会議などが増えてきているのではないでしょうか？

こういった背景から独自のビデオチャット環境を用意したい方向けに、 今回は
『Dockerと「Jitsi Meet」でビデオチャット環境を構築後、共有ドキュメントの「Etherpad」導入』
する手順をご紹介します！！

「Jitsi Meet」とは…

簡潔に説明すると、Jitsi Meetとは、オープンソースで開発された、
多人数同時ビデオ通話を可能にするWebRTCアプリケーションです。
アカウントを作成したりコンピューターにクライアントソフトをインストールしたりする必要はなく、
ウェブブラウザやスマートフォンから URL にアクセスするだけで、すぐにビデオ会議が利用できます。
ブラウザ以外にも、iOS や Android 対応のアプリが公開されています。

また、Jitsi Meetの特徴的な機能として以下の様な機能が存在します。

  • 会議をYouTube Liveでストリーミングする
  • 会議中にYouTubeビデオを再生する
  • 複数人が同時に画面を共有することが可能
  • 通話時間に制限がない
  • Etherpadに基づく共有テキストドキュメントを利用可能

ビデオ会議ツールとして利用する場合はAWS等を用いてサーバーを用意することで利用可能です。
なお、この Jitsi Meet 用のサーバー環境は Docker に対応しています 。
そのため、自分のサーバー上にDocker Compose で起動する手順を今回はまとめました。

「Etherpad」とは

ウェブベースのオンラインエディタであり、オープンソースソフトウェアです。
複数人でテキストを同時に編集することが可能で、各々の編集した部分を対応する色で示すことも可能です。
また、チャット機能が存在するため、コミュニケーションを取りながらテキストを編集することも可能です。

Jitsi Meetでは設定を変更することでこちらのEtherpadを共有ドキュメントとして使用できます。
そのため今回Etherpadの導入までの手順を記載していきます！

想定する構築環境

下記は実際にローカルで動作した際の環境です。

Docker version 20.10.7
OS 　          Ubuntu20.04

上記の通りLinux上での構築を想定しているので、Windowsの方はWSLを利用して構築しましょう。
また、Dockerを用いて構築するので事前にDocker Engine と Docker Compose のインストールを
行っておきましょう。

環境構築手順1（Jitsi Meet立ち上げまで）

それでは早速環境構築していきましょう。 公式の構築手順はこちらをご覧ください。

1. ソースコード入手

まずはJitsi Meetのソースコードをこちらから取得します。

ソースコードは作業用のディレクトリを作成し、保管することをお勧めします。

2. .env作成

cp env.example .env

.env内にはJitsi Meetの動作に必要な設定値などが含まれるため、
個人でカスタマイズする場合は環境変数を変更した際の影響範囲を理解しておきましょう。

3. .env内の各コンテナパスワードを設定

bash ./gen-passwords.sh

または

./gen-passwords.sh

.envにあるコンテナパスワードは設定されていないので、
あらかじめ用意されたシェルスクリプトを実行し設定します。

4. コンフィグディレクトリの作成

mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}

5. コンテナの起動

docker-compose up -d

6. ブラウザアクセス

https://localhost:8443/

ここまでの手順が終わるとブラウザアクセス可能になっており、以下の画面が表示されていれば
Jitsi Meetを無事導入できています。

環境構築手順2（Etherpad導入まで）

Etherpadはデフォルトでは使用できないため、次の手順に従って実装します。

1. .envファイルを編集

.envファイルの92行目付近のコメントを外す。

ETHERPAD_URL_BASE=http://etherpad.meet.jitsi:9001

95行目付近のコメントを外し、以下の様に編集

ETHERPAD_PUBLIC_URL=https://localhost:8443/etherpad/p/

こちらのコメントを外す記載は公式ドキュメントにはなかったため、詰まりどころでした。
これまでの手順でのJitsi Meetと同様のオリジンにすることでクロスオリジンを回避する
ことができ、Etherpadを利用可能になります。

2. 共有ドキュメントを開くボタンの追加

~/.jitsi-meet-cfg/web/にcustom-config.jsを作成し以下内容を追記します。

config.toolbarButtons = [
    'microphone', 'camera', 'closedcaptions', 'desktop', 'embedmeeting', 'fullscreen',
    'fodeviceselection', 'hangup', 'profile', 'chat', 'recording', 'tileview',
    'settings', 'raisehand', 'etherpad', 'sharedvideo', 'livestreaming',
    'videoquality', 'filmstrip', 'invite', 'feedback', 'stats', 'shortcuts',
    'help', 'mute-everyone', 'mute-video-everyone', 'security'
 ];

Etherpadの項目があるかどうかを確認しましょう。

3. コンテナの起動

docker-compose -f docker-compose.yml -f etherpad.yml up -d

etherpadを追加したため、etherpad.ymlファイルを指定します。

4. ブラウザアクセス

https://localhost:8443/

通話画面に入り、詳細アクションを選択した後に共有ドキュメントを開くボタンを押し、
以下の画面が表示されていれば無事導入できています。

Etherpad導入までの手順でした！

最後に

いかがでしたでしょうか。

Jitsi Meetはこの他にも様々な拡張機能を持つだけではなく、既存のソースコードを編集することで
自分好みのビデオ会議ツールにカスタマイズすることも可能です。
ビデオ会議ツールを選ぶのに悩んでいる方、自分だけのビデオ会議ツールを作成したい方等は
是非触れてみてはいかがでしょうか。

☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください！
recruit.styleedge-labo.co.jp

AWSについて

インフラ AWS

はじめに

この4月よりスタイル・エッジLABOに新卒入社したMKです！
インプットがたくさんあり、毎日頭がいっぱいいっぱいです…
それでも親切な先輩たちの協力のもと楽しんで仕事しています😊

そんな私が紹介するのは… 「AWS」についてです！！！ 私自身も知識が浅い部分はあるので、
今回は概要だけですが イメージだけでもしていただけたらうれしいです。

「AWS」って…?

AWSとは、Amazon Web Service の略で
Amazon が提供しているクラウドコンピューティングサービスの総称です。

クラウドコンピューティングとは…?

今日よく聞く言葉ですね🤔
一言でいうと、
インターネットを経由してサーバやストレージなどのサービスを利用できる形態です。
AWSは通販で有名な Amazon が、自社のノウハウを活かして提供しています。

クラウドコンピューティングのサービスが登場する前までのサーバの運用形態は
オンプレミスといいます。
これは、自社でサーバ機器などを設置して利用するというものです。

クラウド VS オンプレミス

ここで、クラウドとオンプレミスを比較した表を作成してみました！ 表からわかることは、以下のことですね。

  • クラウドは、構築期間やスケールの操作時間が短く、導入・運用ともにコスト面でも優位
  • オンプレミスは自由にカスタマイズできる

カスタマイズ性に関しては、一般的にはオンプレミスのほうが自由度は高いですが、
AWSは様々な提供サービスを組み合わせることでサーバ構築を行うので
自由度は高いと思われます！！

サービス紹介

AWSは165種類以上のサービスを提供しています。 用途に応じた多種多様なサービスがあるのですが、
ここでは、私自身が調べたもの次の2つを紹介したいと思います！！

Amazon EC2(Amazon Elastic Compute Cloud)

用途に応じたスペックを自由に組み合わせて仮想サーバを作成・利用できるサービスです。
仮想サーバといえば、クラウドのほかにレンタルサーバというものがあります。 違いは、
クラウド → 借りた道具を使って自分でサーバを作る
レンタルサーバ → マシンや機能を借りる
といったイメージです。
「自分で作る」というと難しい…と思うかもしれませんが
EC2では、画面上からボタンをクリックするだけで簡単に作成することができます。
また、サーバマシンの組み合わせやOS・ソフトウェアの組み合わせなどが用意されているため
それを選択するだけでもサーバ構築ができるのです！

Amazon ELB(Amazon Elastic Load Balancing)

AWSが提供しているロードバランサーです。
ロードバランサーとは、サーバに集中するアクセスを、
複数のサーバやネットワークに振り分ける仕組みです。

サーバにアクセスが集中してしまうとサーバに接続できなくなり、
結果的にサイトが見えなくなるという状態になってしまいます。
そうなる状態を避けるため、ロードバランサーを活用しています。

最後に

今回は「クラウドコンピューティングとは?」の概要とAWSのサービス2つを紹介しました。
他のサービスも利用して、高速かつ安定したサービスを提供できるように
日々試行錯誤し、システムを運用しています！！

弊社の風土として

「システム開発」と聞くとアプリケーションをイメージしがちですが
本格的にインフラ構築に関わることができます！

また、自身の興味に応じてプロジェクトを異動できるため
「インフラにも興味あるし、アプリケーション開発にも関わりたい…」という人にピッタリだと思います😉

☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください！
recruit.styleedge-labo.co.jp