| OSS - Web HA - Websites without crashes during Cybers |
|
Focus on your business, we help you maintain the technological operation without interruptions... With OSS HA Web, your company will have everything you need to make your corporate site work smoothly at Cyber Day or Cyber Monday events, CHILEOFFSHORE provides an architecture that is already working in many successful sites, such as La Polar or Internal Revenue Service. In this way you will no longer have to resort to "Waiting Rooms" and / or warning screens in case of error. This service provides all the necessary hardware, such as servers, communication equipment and the necessary advice so that your site remains operational, without falls and with good performance. According to our experience, one of the most common problems is: There is no capacity for horizontal growth. In general, this occurs in architectures with 2 servers, a Web server and another server for Database, or in architectures composed of a single server, which contain both the Web site and the Database. 
Diagram 1 - Typical development architectures This type of architecture is right for an informational site, but if your company needs to make high-volume sales and offers during the Cybers, these two architectures are not enough to meet this goal. The first architecture (left) was used in the first version of the SII Internet Income Tax Return at the end of the year 90 and was completely out of service as soon as the Income Tax return began in a massive way.. The architecture on the right is in use in many current sites, it was even the architecture of one of our clients, the one that worked with many difficulties during the Cybers.. The solution to the previous problem is to have an architecture that allows you to grow horizontally.  Diagram 2 - Architecture that solves the saturation of the presentation layer but moves the problem to the data layer. This architecture can solve page construction saturation problems, in other words, presentation layer problems. Depending on how your company's site is built, this architecture can work smoothly if your site's pages don't require many database queries. But if your site is built in such a way that each page requires querying the database, this architecture is not going to work properly. In summary, this architecture solves the presentation layer saturation problem, but moves the problem to the data layer. There are several reasons that can cause database overrun: [A] "Stadium Entrance Gate" effect: When there is a football match between two major teams, there will be a lot of people who want to enter the stadium. Therefore, a small gate can cause the "bottleneck" effect where everyone wants to enter at once but few succeed. This effect can occur in a database environment that does not have adequate control. When a system is for internal use of a company, the number of users is limited. But when you have an application open to the public web, you can not estimate how many users are going to connect and there will be a drop in the peak moments of the Cybers.  Diagram 3 - Saturation of People in an Uncontrolled Entrance ("bottleneck" effect) [B] Repetition of operations that are not necessary..Many sites have queries to the database directly, that is, every time they go to the database they require: connect, authenticate, perform operations such as select/update/delete/insert and close connection to the database. In all these operations the actions of connection, authentication (which are quite expensive from the point of view of the database) and closing of connections are not necessary and can be saved. These extra operations are not visible when your company's site is operating with a limited number of users, but once you enter a Cyber it could quickly fail.  Diagram 4 - Classic database operations [C] Static pages that are not static: this includes content that is supposed to be static (that never or very rarely changes) but in reality, changes quite a bit. Example, catalog of products that according to the existence of stock is displayed or not shown. In this type of catalog, there are page layouts, that for each navigation, the program will go to consult the balance of the product to the DB and then make the decision whether to show the product. It sounds reasonable enough from a business standpoint but depending on how it's implemented it's going to make a big difference. If for each navigation of each Internet user the DB will go to know the balance of each product of a catalog type page, a great demand will be generated towards the DB. One of the possible solutions is to implement a "Push" technique that implies that the DB "publishes" the balance on a regular basis on each web server, in this way it is possible to avoid massive access to the DB.  Diagram 5 - About the accesses to show catalog to Internet users [D] Static page but abusing the database: there are developers who "abuse" the amount of use towards the database. A real example, when an Internet user authenticates against the company site, a token is generated that is a unique identification that records authentication. There are programs that validate this token every time the user changes pages while browsing the site, this does not make any sense. The correct way to use a token is when the user performs operations of the type of query or update data, only in those cases the token must be validated against the database. Create an intermediate layer such as middleware, an ESB (Enterprise Service Bus) such as CHILEOFFSHORE's ApiEMBSwitch, switch, etc. This layer is responsible for, in case of a site of high demand, contain, control and segment traffic from the browsers of Internet users.  Diagram 6 - Correct Architecture In this architecture, the presentation layer programs are responsible for building the pages of the site and preventing access to the database directly: They will do it through the ESB. Although in principle they do not see the benefits directly, most IT people end up accepting that ESB is the best architecture for them, because ESB separates layers in a clear way, so programmers who are responsible for building pages no longer must worry about how data is extracted from their company's database or from a service of another company. especially when extracting data from other companies. If your company is already an Enterprise-level company that has different areas, such as marketing, sales, accounting, finance, IT (IT), etc., it is no longer recommended that IT developers handle all topics. Each programmer has a certain profile in which he performs best. For example, Juan Pérez is good at building user interface, Cecilia Gonzalez is good at handling data and with a lot of database experience. Therefore, it is time to consider separating them and specializing them in the different layers. This improves overall IT performance. ESB-SOA can be implemented 100% in SOA style - Service Oriented Architecture, services capable of answering requirements at the business level. For example, suppose a service called "EvalCredit", which evaluates the possibility of granting credit to a potential client, dependent employee type, for this it is required to know their employment situation (Previred service in Chile) and financial behavior (data provided by Equifax or Santiago Chamber of Commerce), therefore, this SOA service (EvalCredit) will be responsible for calling Previred and then calling Equifax, if this call fails, try calling the Chamber of Commerce. In this way, the EvalCredit service, by encapsulating all calls and error handling, makes them transparent to the presentation layer programs. A real example of EMBSiwtch/EMBIntegrator, is that one of the implemented services performs 60 steps that include internal calls to the company's IT system as well as calls to several external companies to deliver the result. ESB-LocalCaché, there are certain types of services, especially services related to external providers, that are paid. This implies that your company must pay information providers such as Equifax, Previred, etc. by number of calls. Therefore, we must avoid unnecessary calls to save expenses. In certain cases, the result of some services does not change their result very often, therefore, the result of a call 10 minutes ago must be valid for a call in the current time for the same client. In this sense, ESBLocalCaché comes into action, recording the results of the calls. As an example, if calls to EvalCredit are detected for the same client, ESBLocalCaché will return the same result without making repeated calls to external companies. In real computer life, you see programmers who "abuse" calls, simply copy-paste a block of code that makes calls, incorporating them into many different programs without considering the "over- expenditure" of company resources. ESB allows you to control database overload. First, an ESB such as ApiEMBSwitch from CHILEOFFSHORE, has access control to databases with connection-pool implementation. This means that the extra database operations mentioned above will be eliminated:  Diagram 7 - Database Access with Connections Pool Once the ESB system is lifted, a few predefined connections to different databases are opened, which it keeps open. In addition, a predefined number of "services" are assigned that are unique to meet a specific database need, therefore, for each data requirement, each "service" of the ESB obtains a connection from a specific database and performs an operation and then returns the connection to the connection-pool. This eliminates 3 unnecessary steps that are: connect to the database, authenticate, and close the connection. In addition, access management is improved, as in the example of "Entrance Gate of a Stadium", equivalent to putting a few stadium employees to control access in parallel and thus allow the public to enter in a controlled manner. An ESB such as ApiEMBSwitch HA from CHILEOFFSHORE, has the ability to grow horizontally, which implies that it can easily increase the number of servers and thus increase the processing capacity without limit. An ESB like ApiEMBSwitch HA from CHILEOFFSHORE, as the name implies, has fault tolerance. That is, if one of the ApiEMBSwitch HA servers fails, another will take complete control and thus ensure 100% uptime for your company. CHILEOFFSHORE has achieved 100% uptime of ApiEMBSwitch HA in the facilities of our clients. CHILEOFFSHORE offers different architectures.[A] Quick fix named "WEBHA1011 Architecture." With this alternative, depending on how your current site is built, there is a high possibility that your company does not need to make big changes and thus be able to better face the next Cyber. At CHILEOFFSHORE we help you change the architecture to:  Diagram 8 – Architecture WEBHA1011 - Balanced site with a few changes. With this architecture, you can achieve horizontal growth without limit of the presentation layer, but you could saturate the database server depending on the way the pages of the site are built. This architecture includes at least one load balancing server, and you can optionally add another balancing server to tolerate failures automatically. Moreover, 2 or more servers for the presentation layer, allows you to grow in ability to respond to Internet browsing during the Cyber. Optionally, depending on how your current website is built, you should consider how to power the database server(s). CHILEOFFSHORE can help your company by bringing more powerful servers with very competitive prices. [B] Complete Solution requiring modifications ("Architecture: WEBHA1012") In this case, CHILEOFFSHORE proposes the WEBHA1012 solution which is an almost perfect architecture and segmentation of the data layer.  Diagram 9 - WEBHA1012 Architecture - Balanced Site with ESB and Multiple Data Centers In this architecture, your company's site can be hosted in different data centers and thus improve site uptime. In addition, with the help of ESB (ApiEMBSwitch of CHILEOFFSHORE), the capacity of the data layer can be increased. To implement this almost perfect architecture, it requires: web servers for the presentation layer and equipment to perform load balancing of these servers, servers to host the ApiEMBSwitch HA and load balancing equipment of these, to distribute data layer load, and optionally new servers for database. With this architecture and with the help of an ESB, your company can already grow in the data layer. Especially data segmentation requires almost no application change. [C] Customized Solution for Your Company ("WEBHA1021 Architecture")
✓ Architecture design flaw 1 - Presentation layer saturation. Depending on the needs of your company, CHILEOFFSHORE provides several alternatives to solve your performance problems in Cyber events:Alternative 1: Monthly equipment rental.
Alternative 2. Full service with Data Center (DC) housing in CHILEOFFSHORE, this includes:
Full service with third-party Data Center (DC) housing such as SONDA, Entel, or DC of your company, in this case CHILEOFFSHORE provides: |
